ما هو وقت سرقة 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 بنفسه، لأنه لا يرى host. ويبلغه hypervisor بهذه القيمة. في KVM، يكتب host عدّاداً خاصاً بكل 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 هادئاً بينما يكون host محمّلاً فوق طاقته. يصدّر KVM وXen هذه القيمة. أما guest على VMware وHyper-V فعادةً ما يعرض صفراً ثابتاً. تحقّق من المنصة قبل أن تثق بقيمة صفر:

systemd-detect-virt

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

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

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

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 60 وراقبه لمدة دقيقة كاملة قبل استخلاص نتيجة.

يعرض 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 قبل أن تعتبر الوضع سليماً.
• ارتفاعات لبضع نقاط مئوية تستمر ثواني. هذا طبيعي على أي عقدة مشتركة. قد يبدأ بناء لدى جار، أو قد يشغّل المضيف نسخاً احتياطية.
• نسبة مستمرة من 1 إلى 5 بالمئة على خطة مشتركة. هذا متوقع. تعكس التكلفة استخدام CPU مشتركاً.
• نسبة مستمرة من 5 إلى 10 بالمئة. هذا تباطؤ يمكنك قياسه. ابدأ بتسجيل الأدلة، وقارن الساعات نفسها على مدار عدة أيام.
• أكثر من 10 بالمئة لعدة ساعات متواصلة. العقدة محمّلة بأعمال أكثر من قدرتها بالنسبة إلى عبء العمل لديك. هذا هو المستوى الذي يبرر فتح تذكرة دعم أو الانتقال إلى عقدة أخرى.

استخدم هذه النطاقات كدليل للقراءة، لا كمواصفة، لأن أي مزود لا ينشر ضماناً بشأن steal في الخطة المشتركة. قيّمها بالارتباط مع ما تشغّله. يمكن لمهمة دفعية ليلية تحمّل 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 تعيد توزيع مهامك على الأنوية التي مُنحت لك فعلياً، ولا يمكنها استعادة دورات المعالجة التي استحوذ عليها جار من قبل. هناك أربعة إجراءات فعلية.

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

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

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

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

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

FAQ

ما مقدار وقت CPU المسروق الطبيعي على VPS؟

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

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

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

لماذا يعرض VPS لدي وقت CPU مسروقاً قدره 0 رغم أنه بطيء بوضوح؟

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

هل يمكنني تقليل وقت CPU المسروق من داخل الخادم؟

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