ما هو وقت سرقة CPU وكيف تكشف جار VPS المزعج؟

ما الذي يقيسه وقت سرقة CPU فعلياً

وقت سرقة CPU هو نسبة الوقت الذي كانت فيه CPU الافتراضية جاهزة للتنفيذ، من دون وجود ما تنتظره، بينما منح الـhypervisor النواة الفعلية لضيف افتراضي آخر. كانت المهام في قائمة الانتظار. وكانت النواة مشغولة في مكان آخر. يحسب Linux هذه الدورات بشكل منفصل ويعرضها بوصفها st، وبذلك يمكنك التمييز بين «خادمي مشغول» و«خادمي ينتظر دوره».

هذا الفرق هو السبب الكامل لوجود هذا العداد. يُعرض الوقت الذي تقضيه عملياتك على CPU بوصفه us (user) أو sy (system). ويُعرض الوقت الذي تقضيه المهمة وهي محجوبة بانتظار التخزين بوصفه wa (I/O wait). أما vCPU (CPU افتراضية) القابلة للتنفيذ، الموجودة في run queue، من دون وجود عمليات I/O معلّقة، والتي لا تزال لا تعمل، فيُعرض وقتها بوصفه st. لا يستطيع أي شيء داخل خادمك إزالة هذه الحالة، لأن قرار الجدولة يُتخذ في طبقة أدنى منك، على المضيف.

ينتج ذلك مباشرة عن كيفية مشاركة VPS واحد بين عدة ضيوف على جهاز فعلي واحد. السبب المعتاد هو جار: ضيف افتراضي آخر على العقدة نفسها يعمل بحمل مرتفع، لذلك يقسم المضيف الأنوية بينكما. وهناك سبب ثانٍ غالباً ما يُغفل. يحدّد العديد من مزوّدي الخدمة vCPU مشتركة بنسبة من نواة فعلية، وفي عدة hypervisors يُحتسب هذا الحد المفروض بوصفه وقت سرقة داخل الضيف. لذلك تخبرك قراءة st المرتفعة بأن النواة لم تُمنح لك. لكنها لا تخبرك دائماً بمن استحوذ عليها.

مصدر قيمة steal

لا يستطيع kernel قياس steal بمفرده، لأنه لا يرى المضيف. يزوّده hypervisor بهذه القيمة. في KVM، يكتب المضيف عدّاداً لكل vCPU في صفحة مشتركة مع guest، ثم يجمعه guest عندما يكون kernel مبنياً مع CONFIG_PARAVIRT_TIME_ACCOUNTING، وهو ما يتوفر في كل kernel توزّعه التوزيعات. يقدّم Xen القيمة نفسها عبر منطقة runstate الخاصة به. تصل القيمة الإجمالية إلى userspace في موضع واحد فقط:

head -1 /proc/stat

يحمل سطر cpu عشرة عدّادات بوحدة نبضات USER_HZ منذ الإقلاع، وبالترتيب التالي: user، وnice، وsystem، وidle، وiowait، وirq، وsoftirq، وsteal، وguest، وguest_nice. قيمة steal هي القيمة الثامنة بعد اسم الحقل. تقرأ كل الأدوات التالية، وهي vmstat وtop وmpstat، وأي Prometheus exporter، الحقل نفسه وتحول عينتين منه إلى نسبة مئوية.

توجد نتيجة مهمة تفوق سواها. إذا لم يصدّر hypervisor العدّاد مطلقاً، فسيبقى الحقل صفراً إلى الأبد، وستعرض كل أداة مبنية عليه 0.0 هادئاً بينما يكون المضيف محمّلاً بشدة. يصدّر KVM وXen هذا العدّاد. أما في المنصات الأخرى، ومنها VMware وHyper-V، فظهور steal يعتمد على ما يتيحه المضيف وعلى ما يدعمه guest kernel. لذلك لا يثبت الصفر المستقر شيئاً بمفرده. افحص المنصة قبل أن تثق في الصفر:

systemd-detect-virt

يطبع هذا الأمر اسم المنصة، مثل kvm أو xen أو vmware أو microsoft، ويطبع none على bare metal. داخل container، يعرض runtime بدلاً من ذلك، مثل lxc أو docker أو podman، وهذا يخبرك عن container لا عن الجهاز الموجود تحته. على kvm، يكون الصفر دليلاً فعلياً على أن المضيف يعاملك جيداً. أما في منصة لا تملأ الحقل مطلقاً، فلا يقدم الصفر أي دليل، ويجب تقييم التنافس عبر قياس زمن تنفيذ العمل الفعلي بدلاً من ذلك.

كيف تتحقق من وقت سرقة CPU على VPS؟

يأتي vmstat من حزمة procps. وهي موجودة في معظم صور Ubuntu وDebian الخاصة بـVPS، لكنها مفقودة في بعض صور الحاويات الدنيا، لذلك ثبّتها قبل الاعتماد عليها.

sudo apt-get update
sudo apt-get install -y procps
vmstat --version
vmstat 1 5

يطبع vmstat --version سطراً مثل vmstat from procps-ng 4.0.4. إذا ظهر هذا السطر، فالأداة مثبّتة وأنت تقرأ عدادات حقيقية من kernel. ثم يطبع vmstat 1 5 خمسة تقارير: الأول هو المتوسط منذ الإقلاع، والتقارير الأربعة التالية هي عينات مدتها ثانية واحدة.

procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 1  0      0 3216484  98304 1284360    0    0     4    18   62  110  3  1 96  0  0  0
 2  0      0 3216232  98304 1284360    0    0     0     0  248  431  6  2 84  0  8  0

ابحث عن العمود st داخل كتلة cpu على اليمين. تطبع الإصدارات الحالية من procps-ng عمود gu بعده لوقت الضيف في KVM، لذلك يكون st الثاني من اليمين بدلاً من أن يكون الأخير. اقرأ العمود من اسم العنوان، لأن هذا الموضع تغيّر بين الإصدارات.

تساعد عادتان على إبقاء القراءة دقيقة. السطر الأول للبيانات هو المتوسط منذ الإقلاع، لذلك تجاهله واقرأ الأسطر التي تليه. كما أن عينة واحدة لا تكفي للقياس، لأن وقت السرقة يصل على دفعات: شغّل vmstat 1 61، فهو يعطي ستين عينة مدتها ثانية واحدة بعد سطر المتوسط منذ الإقلاع، وراقب دقيقة كاملة قبل استخلاص نتيجة.

يُبلغ top عن الرقم نفسه في سطر الملخص %Cpu(s)، داخل الحقل المحدد بـ st:

%Cpu(s):  6.2 us,  2.1 sy,  0.0 ni, 83.9 id,  0.0 wa,  0.0 hi,  0.3 si,  7.5 st

للحصول على تفاصيل كل نواة، أضف sysstat:

sudo apt-get install -y sysstat
mpstat -P ALL 1 5

يطبع mpstat صفاً واحداً لكل CPU مع عمود %steal، ويوضح ما إذا كانت المشكلة تؤثر في كل vCPU أو في واحدة فقط. وللاحتفاظ بالسجل الذي يحتاج إليه طلب الدعم، احفظ العينات بدلاً من قراءتها من الشاشة:

date -u | tee -a ~/steal.log
mpstat -P ALL 1 5 | tee -a ~/steal.log

شغّل ذلك من cron خلال الساعات التي تشك في حدوث المشكلة فيها، وسيصبح الملف هو الفارق بين إخبار مزود الخدمة بأن الخادم «بدا بطيئاً الليلة الماضية» وإظهار الدقائق العشر المحددة له.

ماذا تعني قيم steal؟

• قيمة 0.0 مستقرة. هذا يعني أن النظام سليم، أو أن المنصة لا تعرض steal إطلاقاً. تحقّق باستخدام systemd-detect-virt قبل أن تعتبر ذلك مؤشراً إيجابياً.
• ارتفاعات لبضع نقاط مئوية تستمر ثواني. هذا طبيعي على أي node مشترك. قد يبدأ بناء لدى جار، أو قد يشغّل المضيف النسخ الاحتياطية.
• قيمة مستمرة بين 1 و5 بالمئة على خطة مشتركة. هذا متوقع. تعكس تكلفة الخطة استخدام CPU مشتركاً.
• قيمة مستمرة بين 5 و10 بالمئة. هذا تباطؤ يمكن قياسه. ابدأ بتسجيل الأدلة، وقارن الساعات نفسها على مدار عدة أيام.
• أكثر من 10 بالمئة لساعات متواصلة. يعني ذلك إما أن node محمّلة أكثر من اللازم بالنسبة إلى workload لديك، أو أن حد CPU في خطتك يجري تطبيقه، وبعض موفري الخدمة يعرضون هذا الحد على أنه steal. هذا هو المستوى الذي يبرر فتح تذكرة دعم أو الانتقال إلى خطة أخرى.

تعامل مع هذه النطاقات كدليل للقراءة لا كمواصفة، لأن أي موفر خدمة لا ينشر ضماناً لقيمة steal على خطة مشتركة. قيّمها بالاستناد إلى ما تشغّله. يمكن لمهمة batch ليلية تحمّل steal بنسبة 15 بالمئة من دون أن يلاحظ أحد ذلك. أما الخدمة الحساسة لزمن الاستجابة فتُظهر الأثر في p99 قبل وقت طويل من ظهور متوسط مقلق، ولذلك تنتمي أحمال العمل الحساسة لزمن الاستجابة مثل روبوتات التداول إلى أنوية مخصصة.

ما تكلفة steal time عليك؟

الحساب بسيط. إذا استحوذت نسبة s من وقت CPU، فإن مهمة تحتاج إلى مقدار ثابت من وقت CPU ستستغرق 1 / (1 - s) ضعف المدة الزمنية. بالنسبة إلى مهمة تحتاج إلى 60 ثانية من وقت CPU:

[
  {
    "steal_percent": 0,
    "wall_clock_seconds": "60.0"
  },
  {
    "steal_percent": 3,
    "wall_clock_seconds": "61.9"
  },
  {
    "steal_percent": 8,
    "wall_clock_seconds": "65.2"
  },
  {
    "steal_percent": 15,
    "wall_clock_seconds": "70.6"
  },
  {
    "steal_percent": 25,
    "wall_clock_seconds": "80.0"
  },
  {
    "steal_percent": 40,
    "wall_clock_seconds": "100.0"
  }
]

عند نسبة 3 بالمئة، وهي قراءة عادية في خطة مشتركة، تستغرق المهمة 61.9 ثانية بدلاً من 60.0 ثانية. لن يفتح أحد تذكرة بسبب ذلك. عند نسبة 8 بالمئة، تستغرق 65.2 ثانية. وعند نسبة 40 بالمئة، تحتاج المهمة نفسها إلى 100.0 ثانية، ويبدأ طابور كان يُفرَّغ سابقاً في التراكم بدلاً من ذلك.

هذه قيم محسوبة وليست قياسات. يفترض النموذج وجود thread واحد قابل للتنفيذ وتوزيع steal بالتساوي على الفاصل الزمني. غالباً ما تبدو الخدمات الفعلية أسوأ من المنحنى، لأن الشريحة المسروقة قد تقع في منتصف طلب، ثم يتحمل كل ما ينتظر ذلك الطلب التأخير مرة أخرى. للحصول على قيمة خاصة ببيئتك بدلاً من استخدام صيغة، نفّذ benchmark على VPS خلال ساعة هادئة ثم مرة أخرى خلال ساعة مزدحمة، وسجّل st لكلتا الفترتين.

هل هو steal أم شيء آخر؟

من السهل الخلط بين steal والأعراض الأخرى. اقرأ العدادات معاً، في سطر vmstat نفسه.

• ارتفاع st مع بقاء r وus منخفضين: لا يمنحك المضيف وقت المعالج. هذا هو steal.
• ارتفاع r بوضوح فوق عدد vCPU لديك، مع ارتفاع us واقتراب st من الصفر: أنت تشغّل أعمالاً أكثر مما تستطيع معالجاتك الخاصة استيعابه. قارن r بمخرجات nproc. هذه زيادة في الاشتراك من جانبك، وليست بسبب جار.
• ارتفاع wa مع اقتراب st من الصفر: المهام محجوبة بانتظار التخزين. هذه مشكلة مختلفة ولها حل مختلف.
• ارتفاع متوسط الحمل مع انخفاض st وus معاً: يحسب مؤشر الحمل أيضاً المهام غير القابلة للمقاطعة. لذلك يشير هذا عادةً إلى جهاز عالق أو mount شبكي متوقف، لا إلى المعالج.

تحتاج الخطط القابلة للزيادة إلى توضيح مستقل. تمنحك هذه الخطط رصيداً يتراكم أثناء الخمول ويُستهلك أثناء الانشغال. وعند نفاده، يثبت المزوّد معدل الاستخدام عند مستوى أساسي. في بعض المنصات يظهر هذا الخفض في المعدل على أنه steal. وفي منصات أخرى لا يمكنك رؤيته من داخل الخادم، وتحصل ببساطة على عدد أقل من دورات المعالج في الثانية. اقرأ وصف الخطة قبل أن تقرر أن السبب يعود إلى جار.

سبب عدم إبلاغ الحاوية عن وقت steal

يُعد steal خاصية للآلة الافتراضية، وليس للحاوية التي تعمل داخلها. تشارك حاوية Docker على VPS الخاص بك /proc للمضيف، ولذلك فإن قيمة st المقروءة داخلها هي قيمة steal الخاصة بـVPS، وهذا هو المطلوب. تختلف المحاكاة الافتراضية المعتمدة على الحاويات والمقدمة على أنها VPS. عند استخدام lxcfs، تُنشأ قيمة /proc/stat داخل الحاوية من حسابات cgroup، وتكون قيمة steal صفراً بحكم التصميم. قد تعرض منظومة المراقبة التي تجمع البيانات من داخل الحاوية فقط صفراً ثابتاً وهادئاً، بينما يعاني الجهاز الفعلي أسفلها من استنفاد الموارد.

داخل الحاوية، العداد الذي يحمل المعنى نفسه هو خنق حصة CPU. في cgroup v2:

cat /sys/fs/cgroup/cpu.stat

يمثل nr_throttled عدد فترات الإنفاذ التي بلغت فيها المجموعة حصتها من CPU، بينما يجمع throttled_usec إجمالي الوقت الذي قضته متوقفة. تعني زيادة nr_throttled أن العملية كانت قابلة للتشغيل لكنها لم تكن تعمل. وهذه هي التجربة نفسها التي يسببها steal، لكن سببها حد ضبطته بنفسك. تحقّق من حدودك أولاً قبل إلقاء اللوم على المضيف، خصوصاً إذا كنت تشغّل خدماتك في Docker على VPS مع تحديد حدود CPU في ملف compose. تضيف المحاكاة الافتراضية متعددة الطبقات موضعاً آخر يمكن أن يضيع فيه الوقت، لأن آلة افتراضية داخل VPS الخاص بك تتحمل وقت steal الخاص بك، إضافة إلى تأخير الجدولة الخاص بها. ضع ذلك في الحسبان إذا كنت تشغّل محاكاة افتراضية متداخلة على VPS.

ما الذي يجب فعله عند استمرار وقت steal

لا يوجد إعداد داخل guest يعالج steal، لأن المجدول الذي يتخذ القرار يعمل خارج guest. ولا يغيّر ترقية kernel ذلك أيضاً؛ إذ إن الجدولة المدركة لذاكرة التخزين المؤقت والمضافة في Linux kernel 7.2 تعيد توزيع مهامك على الأنوية التي مُنحت لك فعلياً، ولا تستطيع استعادة دورات CPU التي أخذها جار مجاور من قبل. هناك أربعة إجراءات فعّالة.

اجمع الأدلة أولاً. سجّل الطوابع الزمنية بتوقيت UTC، ومدة كل حالة، وعدد مرات تكرارها، وما إذا كان mpstat يبيّن تأثر vCPU واحد أو جميع vCPUs. إن تسجيل العينات لمدة أسبوع أكثر فائدة من لقطة شاشة.

افتح تذكرة بهذه البيانات. اطرح سؤالين مباشرين: هل هذه العقدة محمّلة بأكثر من سعتها خلال هذه الفترات؟ وهل يمكن نقل instance الخاصة بي؟ أرفق ناتج vmstat والأوقات الدقيقة. يتعامل مزودو الخدمة مع فترة يمكن إعادة إنتاجها، أما التذكرة التي تكتفي بقول إن الخادم بطيء فستتلقى رداً يطلب تحديد هذه الفترة. ويُعد مقدار العمل الذي يمكنك إسناده إلى مزود الخدمة أحد الفروق العملية بين VPS مُدار وغير مُدار.

اطلب الترحيل. يُعد نقل guest إلى عقدة أقل حملاً إجراءً اعتيادياً لدى مزود الخدمة، ويستلزم عادةً إعادة تشغيل قصيرة. هذا هو الإصلاح الذي لا يكلّف شيئاً، ويحل الحالة الشائعة التي توجد فيها عدة أجهزة افتراضية مجاورة كثيفة الاستهلاك على العقدة نفسها في الوقت ذاته.

اشترِ سعة مخصصة لتجنب التنافس. تحجز خطة vCPU مخصصة سعة CPU لـinstance الخاصة بك، سواءً كانت نواة كاملة أو خيطاً عتادياً كاملاً، وفقاً لمزود الخدمة. وبذلك يتوقف الجيران عن استهلاك دوراتك، ويبقى العداد عند الصفر أو قريباً جداً منه. وقد تترك مهام الصيانة الخاصة بـhypervisor قيمة صغيرة متبقية. هذا الخيار أعلى تكلفة كل شهر، لكنه الحل الصريح لحِمل عمل لا يستطيع تحمّل التفاوت. إذا لم يكن ذلك كافياً، أو كنت تريد أيضاً امتلاك عرض نطاق الذاكرة وحدك، فالخطوة التالية هي خادم مخصص بدلاً من VPS.

أثناء انتظارك لأي من هذه الإجراءات، قلّل أثر steal. شغّل عدداً من خيوط العاملين أقل من عدد vCPUs المتاحة لديك، لأن الخيوط التي لا تستطيع الحصول على نواة لا تضيف سوى عمليات تبديل السياق. انقل أعمال الدفعات إلى الساعات التي تكون فيها العقدة هادئة، وفقاً لما يوضحه سجلك الآن. ثم أعد القياس باستخدام الأمر نفسه خلال الساعات نفسها، حتى تتمكن من تحديد ما إذا كان التغيير قد نجح بدلاً من التخمين.

FAQ

ما هو وقت سرقة المعالج (steal time) الطبيعي على خادم VPS؟

في خطط الاستضافة المشتركة، تُعد الارتفاعات الطفيفة والقيمة المستمرة التي تقل عن 5 بالمئة أمراً عادياً، لأن المعالج المشترك يعني أن المضيف يوزع الأنوية الفيزيائية بين الأنظمة الضيفة. أما استمرار القيمة عند خانتين عشريتين (10 بالمئة أو أكثر) لساعات فليس أمراً عادياً، ويستحق فتح تذكرة دعم. في خطط vCPU المخصصة، القيمة المتوقعة هي 0.0 أو قريبة جداً منها، حيث يمكن لعمليات إدارة الـhypervisor أن تستهلك جزءاً بسيطاً، لذا فإن استمرار وقت السرقة فوق ذلك يعد خللاً يجب الإبلاغ عنه. قيّم الرقم بناءً على طبيعة عملك: وظيفة معالجة دفعية (batch job) خلال الليل قد تتحمل وقت سرقة لا يمكن لواجهة برمجة تطبيقات (API) حساسة لزمن الاستجابة تحمله.

هل ستؤدي الترقية إلى خطة أكبر إلى حل مشكلة وقت السرقة المرتفع؟

ليس بالضرورة. المزيد من vCPUs على نفس العقدة المشتركة يعني المزيد من المعالجات الافتراضية التي تتنافس على نفس الأنوية الفيزيائية المزدحمة، وقد تظل النسبة كما هي تماماً. ما يزيل وقت السرقة تقريباً هو تخصيص معالج مخصص (dedicated CPU)، أو الانتقال إلى عقدة أقل ازدحاماً. الحصول على حصة أكبر من جهاز مزدحم يظل حصة من جهاز مزدحم.

لماذا يظهر وقت سرقة المعالج 0 على خادم VPS الخاص بي رغم أنه بطيء بوضوح؟

هناك سببان شائعان لذلك. قد لا يقوم الـhypervisor بتصدير العداد على الإطلاق، وهو ما يحدث في بعض المنصات اعتماداً على المضيف ونواة النظام الضيف، فيظل الحقل صفراً بغض النظر عما يفعله المضيف. شغّل systemd-detect-virt لمعرفة المنصة التي تعمل عليها. بخلاف ذلك، قد يكون الاختناق في مكان آخر: تحقق من wa لرصد فترات انتظار التخزين، وقارن r مع nproc لمعرفة ما إذا كان الحمل الزائد ناتجاً عنك، واقرأ /sys/fs/cgroup/cpu.stat داخل الحاويات للتحقق من تقييد الحصص (quota throttling).

هل يمكنني تقليل وقت سرقة المعالج من داخل خادمي؟

لا يمكنك تغيير جدولة المضيف من داخل النظام الضيف. يمكنك فقط تقليل تأثيرها. شغّل عدداً من خيوط المعالجة (worker threads) أقل من عدد vCPUs المتاحة لديك، لتقليل حجم العمل المنتظر في طابور التنفيذ لنواة لن تتوفر. انقل الوظائف الدفعية إلى الساعات التي تكون فيها العقدة أقل ازدحاماً. خزّن النتائج مؤقتاً (cache) لتقليل عدد الطلبات التي تحتاج إلى معالجة. التغييرات التي تزيل وقت السرقة فعلياً، مثل الترحيل إلى عقدة أخرى أو استخدام أنوية مخصصة، تقع ضمن صلاحيات مزود الخدمة.