CPU Throttling في Kubernetes: ليه بودك بطيء والمعالج مستريح؟

احسب نسبة الكبح: nr_throttled / nr_periods. لو النسبة فوق 25%، عندك مشكلة حقيقية بتدفع تكلفتها latency. على مستوى الكلاستر كله استخدم Prometheus بدل ما تدخل كل بود بإيدك:

سيناريو واقعي بأرقام

خدمة Node.js بتعمل image processing، محطوط عليها limits.cpu: "1"، وبتشغّل thread pool بـ 8 خيوط على عقدة 16 vCPU. تحت حمل 900 طلب/ثانية: الـ p99 كان 2100ms، ومتوسط استهلاك الـ CPU المعروض 55%، ونسبة الكبح من cpu.stat كانت 63%. رفعنا الحد لـ "4" فبقت نسبة الكبح 6% والـ p99 نزل لـ 240ms — من غير ما نلمس الكود ولا نكبّر العقدة. الافتراض هنا إن العقدة فيها فسحة CPU فعلاً؛ لو العقدة نفسها مزنوقة، رفع الحد بيأجّل المشكلة مش بيحلّها.

الحلول والـ trade-offs

1. ظبط الحد على درجة التوازي الحقيقية. لو تطبيقك بيشغّل 4 خيوط فعّالة، حدّ "1" غلط من الأساس. خلّي الحد ≥ عدد الخيوط النشطة. المكسب: الكبح بيختفي. الخسارة: بودات أقل على كل عقدة.
2. قلّل توازي التطبيق نفسه بدل ما تكبّر الحد. في Go اضبط GOMAXPROCS ليساوي حدّ الـ CPU (استخدم مكتبة automaxprocs). في الـ JVM اضبط -XX:ActiveProcessorCount. المكسب: التطبيق بيحترم حدّه من جوّه فيقلّل التنافس. الخسارة: أقصى throughput لكل بود بيقل.
3. شيل حدّ الـ CPU خالص واعتمد على requests بس. ده بيلغي الكبح تمامًا. الـ trade-off هنا حقيقي وصريح: بتكسب latency، بتخسر العزل — بود واحد ممكن ياكل CPU الجيران وقت الذروة (noisy neighbor). ينفع لو بتثق في الـ requests وعندك مراقبة كويسة على العقدة.

تحذير على مستوى الـ kernel

لو الكلاستر شغّال kernel أقدم من 5.4، فيه باج معروف في CFS كان بيكبح أكتر من اللازم حتى لو استهلاكك تحت الحد. الإصلاح دخل في نواة 5.4، وميزة cpu.cfs_burst_us اللي بتسمح باستهلاك انفجاري محدود دخلت في 5.14. الافتراض إن معظم شروحات "شيل الـ limits" القديمة اتكتبت في زمن الباج ده؛ على kernel حديث الموضوع أهدى بكتير، فاقيس على نُواتك انت قبل ما تاخد قرار جذري.

متى لا تستخدم هذه الطريقة

لو نسبة الكبح عندك تحت 5%، سيبها؛ مش كل throttling مشكلة تستاهل وقتك. ولو شغّال على منصّة مشتركة (multi-tenant) والعزل عندك أهم من آخر 100 مللي ثانية latency، متشيلش الـ limits — الكبح هنا هو الميزة مش العيب. وكمان لو حِملك CPU-bound فعلاً وثابت (مش انفجاري)، رفع الحد مش هيساعد كتير؛ محتاج تحسّن الكود نفسه أو تكبّر أفقيًا.

الخطوة التالية

افتح أكتر خدمة بتشتكي من الـ latency، ونفّذ cat /sys/fs/cgroup/cpu.stat جوّه بودها واحسب nr_throttled / nr_periods. لو طلعت فوق 25%، جرّب ترفع الحد أو تظبط GOMAXPROCS وقيس الـ p99 قبل وبعد. الرقم ده لوحده بيحسم إذا كنت بتدفع فاتورة كبح إجباري من غير ما تدري.

المصادر

• Kubernetes Docs — Managing Resources for Containers (CPU limits): https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
• Linux Kernel — CFS Bandwidth Control (sched-bwc): https://www.kernel.org/doc/html/latest/scheduler/sched-bwc.html
• Kubernetes Issue #67577 — CFS quotas can lead to unnecessary throttling: https://github.com/kubernetes/kubernetes/issues/67577
• Linux commit de53fd7aedb1 — sched/fair: fix low CPU usage with high throttling (نواة 5.4): https://github.com/torvalds/linux/commit/de53fd7aedb1
• Linux Kernel — cgroup v2 CPU controller (cpu.stat): https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html