لا أكتب هذا باعتباره مراجعة سلبية لـ AVA Hosting.
إنه ببساطة يوم عادي من أيام عملي كمطور: خادم يتصرف بصورة سيئة، والتفسيرات الواضحة لا تنطبق، ثم يكشف Linux في النهاية ما الذي يحدث.
كان لدي خادم KVM VPS صغير من AVA Hosting بالمواصفات التالية:
1 vCPU
2 GB RAM
25 GB NVMeكان يشغّل حمولة إنتاج عادية. كان Nginx يعمل، والـ backend يعمل، والذاكرة المتاحة موجودة، والقرص لم يكن ممتلئًا.
لكن الخادم لم يكن قادرًا على مواكبة العمل.
لذلك أجريت مراقبة سلبية لمدة 60 ثانية أثناء حركة الإنتاج العادية، من دون stress test أو تدفق HTTP اصطناعي أو benchmark للقرص.
كانت النتيجة:
vCPU count: 1
Average CPU user: 52.52%
Average CPU system: 8.07%
Average CPU softirq: 6.69%
Average CPU steal: 32.73%
Average CPU iowait: 0.00%
Average CPU idle: 0.00%
Maximum runnable queue: 11الرقم الذي كان يهم فعلًا هو 32.73% CPU steal. عندها تغير التشخيص بالكامل.
لماذا فاجأني ذلك
تعلن AVA Hosting حاليًا عن خدمة VPS بعبارة “Guaranteed resources — no sharing”. كما تصف صفحاتها تخصيص vCPU بأنه ثابت أو مخصص، وتقول إن أداء الخادم لا ينبغي أن يتأثر بعملاء آخرين. وفي مواد Linux VPS تذهب AVA أبعد من ذلك، إذ تقول إن حمولة CPU كثيفة لدى مستأجر آخر على الخادم نفسه لا يمكنها أن تسبب steal time لخادمي، كما تذكر صفحة أخرى أن CPU steal يتم التخلص منه على مستوى الـ hypervisor.
هذه ادعاءات محددة جدًا. لم تكن المسألة مجرد صفحة تعرض 1 vCPU من دون توضيح نموذج توزيع المعالج. كانت AVA تعلن صراحةً عن حماية من النوع نفسه من تنازع CPU الذي كان Linux يبلغ عنه داخل آلتي الافتراضية.
ماذا يعني CPU steal؟
steal مقياس عادي في Linux لوقت المعالج داخل البيئات الافتراضية. وهو يمثل الوقت الذي كان لدى النظام الضيف فيه عمل قابل للتنفيذ، لكن الـ vCPU لم يكن يعمل فعليًا.
وهذا يختلف عن أن يستهلك تطبيقي كامل قدرة المعالج. لو رأيت قرابة 100% في user/system مع 0% steal و0% idle، لكان استنتاجي ببساطة أن الحمولة تحتاج إلى قدرة معالجة أكبر.
لكن في حالتي كان نحو ثلث محاسبة وقت CPU يندرج تحت steal.
من داخل النظام الضيف لا أستطيع رؤية hypervisor الخاص بـ AVA، ولا معرفة حمل الخادم الفيزيائي أو عدد الآلات الافتراضية المجاورة أو سياسة CPU pinning أو نسبة overcommit. ما أستطيع رؤيته هو ما أبلغه Linux: كان الـ vCPU يتوقف مرارًا عن التنفيذ بينما توجد أعمال تنتظر المعالجة.
المشكلة كانت مستمرة وليست قفزة لثانية واحدة
عينة سيئة واحدة لم تكن لتقنعني، لذلك راقبت الخادم باستمرار لمدة 60 ثانية. لم أشغل stress test أو تدفق HTTP اصطناعيًا أو benchmark للقرص.
كانت العينات المتتابعة تبدو بهذا الشكل:
%usr %sys %soft %steal %idle
53.54 10.10 5.05 31.31 0.00
56.44 6.93 5.94 30.69 0.00
51.52 7.07 6.06 35.35 0.00
55.45 6.93 5.94 31.68 0.00
51.49 8.91 5.94 33.66 0.00
52.53 7.07 7.07 33.33 0.00
52.48 6.93 7.92 32.67 0.00وقرب نهاية المراقبة ظل النمط نفسه قائمًا:
50.98 10.78 6.86 31.37 0.00
48.48 8.08 9.09 34.34 0.00
55.00 5.00 7.00 33.00 0.00أما المتوسط الكامل فكان:
user: 52.52%
system: 8.07%
softirq: 6.69%
steal: 32.73%
iowait: 0.00%
idle: 0.00%إذًا لم تكن مجرد حالة جدولة عابرة. طوال معظم الدقيقة بقي steal عند نحو 30% أو أكثر، بينما ظل CPU idle عند الصفر.
للتصور، 32.73% من دقيقة تساوي نحو 19.64 ثانية. هذا لا يعني أن الـ VPS تجمد 19.64 ثانية متواصلة، بل إن فترات عدم جدولة الـ vCPU الصغيرة تراكمت إلى هذا المقدار تقريبًا.
الـ backend لم يستطع اللحاق بالطلبات
ظهرت مشكلة CPU أيضًا على مستوى التطبيق. قبل المراقبة كانت قائمة انتظار الاستماع في الـ backend:
Recv-Q: 168
Send-Q: 511وبعد 60 ثانية:
Recv-Q: 166
Send-Q: 511الأرقام الدقيقة ليست هي المهم. المهم أن قائمة الانتظار لم تنخفض فعليًا. كان لدى التطبيق دقيقة كاملة للحاق بالطلبات، لكنه بقي متأخرًا.
كان هناك أيضًا عدد كبير من اتصالات CLOSE-WAIT. لا أنسب ذلك وحده إلى المضيف، لأن هذه الحالة قد ترتبط كذلك بطريقة إدارة الاتصالات داخل التطبيق. لكن الصورة الكاملة كانت متسقة:
1 vCPU
32.73% steal
0% idle
~99% CPU pressure
elevated runnable queue
backend queue not drainingكان الخادم حيًا، لكنه لم يكن سليمًا.
الذاكرة والقرص لم يكونا الاختناق الواضح
فحصت الأسباب المعتادة. كانت الذاكرة كالتالي:
RAM total: ~1.9 GiB
RAM available: ~959 MiB
Swap total: 2 GiB
Swap used: ~33 MiBكان هناك قدر كبير من الذاكرة المتاحة، ولم يظهر حدث OOM واضح يفسر السلوك.
أما نظام الملفات:
24 GB total
14 GB used
9.4 GB available
60% usedوكان متوسط CPU I/O wait يساوي 0.00%. في المقابل ظل CPU pressure قريبًا من 99%، وكان load average نحو 3.5–4 على VM ذات vCPU واحد، ووصل runnable queue إلى 11.
كل هذه القياسات أشارت إلى الاتجاه نفسه: الخادم كان يعاني نقصًا في وقت CPU، لا اختناقًا واضحًا في RAM أو التخزين.
التناقض مع صياغة AVA
هذه أكثر نقطة أثارت اهتمامي.
تقول AVA “Guaranteed resources — no sharing”. وتقول إن الأداء لا ينبغي أن يتأثر بعملاء آخرين. وتذكر مواد Linux VPS أن مستأجرًا آخر لا يستطيع إدخال steal time، بينما تقول صفحة أخرى إن CPU steal يُلغى على مستوى hypervisor.
أما الـ VPS الذي حصلت عليه من AVA فأظهر:
Average CPU steal: 32.73%لا أستطيع من داخل الـ VM إثبات السبب الدقيق. لا أستطيع إثبات overselling متعمد، ولا تحديد حمولة مجاورة بعينها، ولا إعادة بناء إعدادات CPU على المضيف لدى AVA.
كما أنني لا أقول إن كل VPS لدى AVA Hosting يتصرف بهذه الطريقة. لقد اختبرت خادمًا واحدًا.
لكن يمكنني القول إن السلوك الذي قسته يصعب جدًا التوفيق بينه وبين هذه الادعاءات المحددة حول عزل CPU. وهذا يكفي لهذه المقالة.
لماذا لم أقم بالترقية
الرد الواضح كان شراء المزيد من vCPU.
لو كان الخادم يعطيني steal قريبًا من الصفر وكان تطبيقي يستهلك النواة كاملة، لكانت الترقية منطقية. لكن نحو ثلث محاسبة CPU في القياس كان steal.
لم أرغب في دفع ثمن معالجات افتراضية إضافية قبل فهم سبب تسجيل جزء كبير من وقت تنفيذ أول vCPU على أنه غير متاح. لذلك ألغيت الـ VPS وطلبت استرداد المبلغ.
AVA أعادت المبلغ كاملًا وبسرعة
هذا الجزء من التجربة كان جيدًا.
أعادت AVA Hosting كامل المبلغ. تمت معالجة الاسترداد بسرعة، ولم يقضوا أيامًا في الجدال معي حول قياسات CPU. شرحت المشكلة، وطلبت استرداد المال، وتم ذلك.
وأنا أقدر ذلك.
لذلك خرجت من التجربة باستنتاجين منفصلين: الـ VPS الذي حصلت عليه كان يعاني مشكلة خطيرة في توفر CPU، وAVA تعاملت مع طلب الاسترداد بصورة جيدة. كلا الأمرين صحيح.
ما الذي تعلمته من التجربة
لم أعد أحكم على VPS فقط من مواصفات مثل 1 vCPU / 2 GB RAM / NVMe / KVM. هذه الأرقام تخبرني بما تم provision له، لكنها لا تخبرني بمدى ثبات توفر CPU تحت حمولة حقيقية.
الآن، من أول الأشياء التي أفحصها على أي آلة افتراضية جديدة:
mpstat 1 60
vmstat 1 60
cat /proc/pressure/cpu
ss -ltnp
free -h
df -h
iostat -xz 1 60أهم ما تعلمته من تجربتي مع AVA Hosting ليس أن vCPU واحد قليل. بل أن عملية تعمل، وذاكرة متاحة، وقرصًا يبدو سليمًا قد تخفي تحتها مشكلة مختلفة تمامًا.
في حالتي أوضح Linux المشكلة بشكل غير معتاد:
CPU steal: 32.73%
CPU idle: 0.00%
CPU pressure: ~99%AVA Hosting تعلن عن موارد CPU من دون مشاركة وتقول إن steal الناتج عن أحمال الجيران لا ينبغي أن يحدث. الـ VPS الذي حصلت عليه أبلغ عن شيء مختلف.
ألغيت الخادم، وأعادت AVA كامل أموالي بسرعة ومن دون جدال.
وهكذا انتهى يوم التشخيص هذا.