هذا المقال يتطلب مستوى: متوسط. لو تعرف يعني إيه Pod و limit في Kubernetes، وتقدر تشغّل kubectl، انت جاهز. المثال المبسّط في الأول هيوصّل الفكرة حتى لو انت مبتدئ.

CPU Throttling في Kubernetes: ليه خدمتك بطيئة والمعالج فاضي

لو زمن الاستجابة عندك عالي والـ CPU usage واقف عند 40%، بلاش تكبّر السيرفر. غالبًا المشكلة إن الـ CPU limit بيخنق الحاويّة، والحل ممكن يكون تعديل سطر واحد ينزّل الـ P99 من 870 لـ 110 مللي ثانية.

المشكلة باختصار

بتحط resources.limits.cpu على الحاويّة عشان تحميها. لكن الـ limit ده مش سقف متوسط، ده سقف لحظي صارم. لو خدمتك احتاجت CPU أكتر من الحصة في جزء بسيط من الثانية، Kubernetes بيوقفها إجباريًا لباقي الفترة. النتيجة: طلبات بطيئة ومتقطّعة، بينما متوسط الـ CPU على الجرافات يبان منخفض. ده اسمه CPU Throttling.

مثال يوصّل الفكرة

تخيّل موظف شاطر يخلّص أي مهمة في دقيقتين. بس المدير حاطط قاعدة غريبة: ممنوع تشتغل أكتر من 4 دقايق في كل ربع ساعة. أول ما الموظف يخلّص مهمتين يعني 4 دقايق، بيتقفل عليه الباب باقي الـ 11 دقيقة، حتى لو الشغل متراكم قدامه. لو وصلت 3 مهام في نفس الربع ساعة، التالتة هتستنى للربع الجاي. الموظف مش بطيء، والمكتب مش مزحوم. القاعدة نفسها هي المشكلة.

ده بالظبط اللي بيحصل مع الـ CPU limit. الموظف هو الحاويّة، وقاعدة 4 دقايق في كل ربع ساعة هي الـ CFS quota.

الشرح العلمي: CFS Quota و Period

لينكس بيدير الـ CPU بجدول اسمه Completely Fair Scheduler أي CFS. لما تحط limit على حاويّة، Kubernetes بيترجمه لقيمتين على مستوى الـ cgroup:

• cfs_period_us: طول النافذة الزمنية، وافتراضيًا 100000 ميكروثانية أي 100 مللي ثانية.
• cfs_quota_us: كام ميكروثانية CPU مسموح للحاويّة تستهلكها داخل كل نافذة.

لو حطّيت الـ limit بنص كور، الـ quota بتبقى 50000 لكل period طوله 100000. يعني الحاويّة تشتغل 50 مللي ثانية بس في كل 100 مللي ثانية. لو استهلكت الحصة في أول 40 مللي ثانية، بتتوقف 60 مللي ثانية كاملة لحد النافذة الجديدة. الافتراض المهم هنا إن الحساب لحظي لكل 100 مللي ثانية، مش متوسط على الثانية أو الدقيقة.

الخطير إن التطبيقات متعددة الـ threads بتستهلك الـ quota أسرع. تطبيق بـ 4 threads و limit قدره 1 كور ممكن يخلّص حصته في 25 مللي ثانية، ويقعد مخنوق 75 مللي ثانية في كل نافذة. عشان كده الـ throttling بيظهر بقوة في تطبيقات JVM و Node و Go تحت الحمل.

إزاي تكتشف الـ Throttling بنفسك

المقياس الحاسم موجود في cgroup وبيتصدّر لـ Prometheus باسم container_cpu_cfs_throttled_periods_total. قارنه بإجمالي الـ periods عشان تطلّع نسبة الخنق:

rate(container_cpu_cfs_throttled_periods_total[5m])
/
rate(container_cpu_cfs_periods_total[5m])

لو مالكش Prometheus، اقرا القيمة الخام من داخل الحاويّة على أنظمة cgroup v2:

kubectl exec -it my-pod -- sh -c 'cat /sys/fs/cgroup/cpu.stat'
# nr_periods, nr_throttled, throttled_usec

القاعدة العملية: أي نسبة throttling فوق 5% تحت الحمل تستحق تدخّل. في حالة خدمة checkout حقيقية كانت النسبة 63%، وده اللي كان بيرفع الـ P99 لـ 870 مللي ثانية.

الحل: اضبط الحصة صح

الفكرة إنك تدّي الحاويّة سقف يسمح بالذروة القصيرة بدل ما تخنقها. رتّب الخطوات بالأولوية:

1. ارفع أو شيل الـ CPU limit وخلّي حمايتك عبر requests اللي بتضمن حصة عادلة من غير سقف صارم.
2. اضبط requests على الاستهلاك الفعلي يعني P95 من الاستخدام مثلًا عشان الجدولة تبقى سليمة.
3. لو محتاج سقف، خلّيه واسع 2 كور مثلًا مش ضيّق.

resources:
  requests:
    cpu: 500m
    memory: 256Mi
  limits:
    cpu: 2
    memory: 256Mi

بعد رفع الحصة من نص كور لـ 2 كور، نزلت نسبة الـ throttling لأقل من 2%، والـ P99 من 870 لـ 110 مللي ثانية، أي تحسّن حوالي 7.9 أضعاف بنفس العتاد.

الـ trade-off هنا

مفيش حل ببلاش. رفع أو إزالة الـ CPU limit بيكسب سرعة وثبات، بس بتخسر ضمان العزل الصارم: حاويّة واحدة تحت حمل غير طبيعي ممكن تاكل CPU أكتر وتزاحم الجيران على نفس الـ node. الافتراض إن عندك requests مضبوطة وعدد replicas كافٍ، والـ node مش مكدّس فوق طاقته. لو دي مضمونة، المكسب أكبر من المخاطرة بكتير.

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

لو بتشغّل بيئة multi-tenant صارمة، أو عندك عميل بيدفع مقابل عزل مضمون، أو workloads batch ممكن تاكل الـ CPU بلا سقف وتضر الخدمات الحسّاسة، سيب الـ limit موجود واقبل الـ throttling كثمن للعزل. كمان لو خدمتك خفيفة ونسبة الـ throttling أقل من 1%، متلمسش حاجة؛ التحسين هنا مش مستاهل.

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

افتح Prometheus دلوقتي وشغّل الاستعلام بتاع container_cpu_cfs_throttled_periods_total على أكتر خدمة بطيئة عندك. لو النسبة فوق 5%، جرّب ترفع الـ CPU limit على staging وقيس الـ P99 قبل وبعد. لو نزل زي ما شرحنا، طبّقه على الإنتاج تدريجيًا.

المصادر

• Kubernetes Docs — Resource Management for Pods and Containers: kubernetes.io/docs/concepts/configuration/manage-resources-containers/
• Linux Kernel Docs — CFS Bandwidth Control: docs.kernel.org/scheduler/sched-bwc.html
• Kubernetes Docs — About cgroup v2: kubernetes.io/docs/concepts/architecture/cgroups/
• cAdvisor Prometheus Metrics: github.com/google/cadvisor/blob/master/docs/storage/prometheus.md