“Guaranteed Resources — No Sharing” کے باوجود میرے AVA Hosting VPS پر اوسط CPU Steal 32.73% رہا

میں یہ AVA Hosting کا منفی review لکھنے کے لیے نہیں لکھ رہا۔

یہ بس ایک developer کے طور پر میرے عام کام کے دنوں میں سے ایک ہے: server خراب چل رہا تھا، واضح وجوہات فٹ نہیں بیٹھ رہی تھیں، اور آخرکار Linux نے دکھایا کہ اصل میں کیا ہو رہا تھا۔

میرے پاس AVA Hosting کا ایک چھوٹا KVM VPS تھا:

1 vCPU
2 GB RAM
25 GB NVMe

اس پر ایک عام production workload چل رہا تھا۔ Nginx چل رہا تھا۔ backend چل رہا تھا۔ memory دستیاب تھی۔ disk بھری ہوئی نہیں تھی۔

اس کے باوجود server workload کے ساتھ رفتار برقرار نہیں رکھ پا رہا تھا۔

اس لیے میں نے عام production traffic کے دوران 60 سیکنڈ کی passive diagnostic observation کی۔ کوئی stress test، synthetic HTTP flood یا disk 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 تھا۔ یہ دیکھنے کے بعد diagnosis مکمل طور پر بدل گیا۔

یہ نتیجہ حیران کن کیوں تھا

AVA Hosting اس وقت اپنے VPS کو “Guaranteed resources — no sharing” کے الفاظ کے ساتھ advertise کرتا ہے۔ اس کی VPS pages vCPU allocation کو fixed یا dedicated بھی بتاتی ہیں اور کہتی ہیں کہ دوسرے customers کی وجہ سے performance متاثر نہیں ہونی چاہیے۔ Linux VPS کے مواد میں AVA اس سے بھی آگے جاتا ہے اور کہتا ہے کہ اسی host پر کسی دوسرے tenant کا CPU-intensive workload آپ کی instance میں steal time پیدا نہیں کر سکتا۔ ایک اور page میں کہا گیا ہے کہ CPU steal hypervisor level پر ختم کر دیا جاتا ہے۔

یہ بہت مخصوص دعوے ہیں۔ یہ محض ایسی VPS page نہیں تھی جس پر 1 vCPU لکھا ہو اور CPU allocation model کا ذکر نہ ہو۔ AVA واضح طور پر اسی قسم کی CPU contention سے protection advertise کر رہا تھا جسے Linux میری VM کے اندر report کرتا نظر آ رہا تھا۔

CPU steal کا مطلب کیا ہے

steal virtualized environments میں Linux کا ایک عام CPU metric ہے۔ یہ اس وقت کو ظاہر کرتا ہے جب guest کے پاس runnable work موجود ہو لیکن virtual CPU حقیقت میں نہ چل رہا ہو۔

یہ اس صورت سے مختلف ہے جب میری application خود تمام دستیاب CPU استعمال کر رہی ہو۔ اگر میں تقریباً 100% user/system، 0% steal اور 0% idle دیکھتا تو میں یہی نتیجہ نکالتا کہ workload کو مزید processing power چاہیے۔

لیکن یہاں CPU accounting کا تقریباً ایک تہائی steal تھا۔

guest کے اندر سے میں AVA کا hypervisor نہیں دیکھ سکتا۔ physical node کا load، neighboring VMs کی تعداد، CPU pinning policy یا overcommit ratio میرے سامنے نہیں۔ میں صرف وہ دیکھ سکتا ہوں جو Linux نے میری VM کو بتایا: کام انتظار میں موجود تھا مگر vCPU بار بار چل نہیں رہا تھا۔

یہ صرف ایک سیکنڈ کا spike نہیں تھا

ایک خراب CPU sample مجھے قائل نہیں کرتا۔ اسی لیے میں نے machine کو مسلسل 60 سیکنڈ measure کیا۔ میں نے جان بوجھ کر کوئی stress test، synthetic HTTP flood یا disk benchmark نہیں چلایا۔

ہر سیکنڈ کے samples بار بار اس طرح نظر آئے:

%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

Observation کے آخر کے قریب بھی یہی pattern موجود تھا:

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

مکمل average:

user:       52.52%
system:      8.07%
softirq:     6.69%
steal:      32.73%
iowait:      0.00%
idle:        0.00%

یعنی یہ مختصر scheduling anomaly نہیں تھی۔ زیادہ تر منٹ steal تقریباً 30% یا اس سے اوپر رہا جبکہ CPU idle صفر رہا۔

اندازہ لگانے کے لیے، ایک منٹ کا 32.73% تقریباً 19.64 سیکنڈ بنتا ہے۔ اس کا مطلب یہ نہیں کہ VPS مسلسل 19.64 سیکنڈ freeze رہا؛ بلکہ وہ چھوٹے intervals جن میں vCPU schedule نہیں ہوا، مجموعی طور پر تقریباً اتنا وقت بنتے ہیں۔

backend backlog ختم نہیں کر پا رہا تھا

CPU کا مسئلہ application level پر بھی دکھائی دے رہا تھا۔ Monitoring سے پہلے backend listen queue:

Recv-Q: 168
Send-Q: 511

60 سیکنڈ بعد:

Recv-Q: 166
Send-Q: 511

Exact numbers اہم نہیں۔ اہم یہ ہے کہ queue عملی طور پر drain نہیں ہوئی۔ Application کے پاس پورا ایک منٹ تھا catch up کرنے کے لیے، مگر وہ پھر بھی پیچھے رہی۔

کافی CLOSE-WAIT connections بھی تھے۔ صرف اس state کی بنیاد پر میں host کو ذمہ دار نہیں ٹھہراؤں گا، کیونکہ application-side connection handling بھی ایسا کر سکتی ہے۔ لیکن مجموعی تصویر consistent تھی:

1 vCPU
32.73% steal
0% idle
~99% CPU pressure
elevated runnable queue
backend queue not draining

Server چل رہا تھا، مگر healthy نہیں تھا۔

RAM اور disk واضح bottleneck نہیں تھے

میں نے عام متبادل وجوہات بھی check کیں۔ Memory:

RAM total:      ~1.9 GiB
RAM available:  ~959 MiB
Swap total:     2 GiB
Swap used:      ~33 MiB

ابھی بھی خاصی memory available تھی اور behavior سمجھانے والا کوئی واضح OOM event نہیں تھا۔

Filesystem:

24 GB total
14 GB used
9.4 GB available
60% used

Average CPU I/O wait 0.00% تھا۔ دوسری طرف CPU pressure تقریباً 99% رہا، ایک-vCPU VM پر load average تقریباً 3.5–4 تھا اور runnable queue 11 تک پہنچ گئی۔

تمام measurements ایک ہی طرف اشارہ کر رہے تھے: machine کو CPU time نہیں مل رہا تھا، جبکہ RAM یا storage واضح طور پر bottleneck نہیں تھے۔

AVA کی wording سے تضاد

میرے لیے یہی سب سے دلچسپ حصہ ہے۔

AVA کہتا ہے “Guaranteed resources — no sharing”۔ وہ کہتا ہے کہ دوسرے customers سے performance متاثر نہیں ہونی چاہیے۔ Linux VPS material کہتا ہے کہ دوسرا tenant steal time پیدا نہیں کر سکتا، اور ایک اور page کہتی ہے کہ CPU steal hypervisor level پر eliminate کر دیا جاتا ہے۔

میرے AVA VPS نے دکھایا:

Average CPU steal: 32.73%

VM کے اندر سے میں exact وجہ ثابت نہیں کر سکتا۔ میں intentional overselling ثابت نہیں کر سکتا، کسی specific neighboring workload کو identify نہیں کر سکتا اور AVA کی host-side CPU configuration reconstruct نہیں کر سکتا۔

میں یہ بھی نہیں کہہ رہا کہ ہر AVA Hosting VPS ایسا behave کرتا ہے۔ میں نے ایک VPS test کیا۔

لیکن میں یہ ضرور کہہ سکتا ہوں کہ جو behavior میں نے measure کیا، اسے ان specific CPU-isolation claims کے ساتھ reconcile کرنا بہت مشکل ہے۔ اس article کے لیے یہی کافی ہے۔

میں نے upgrade کیوں نہیں کیا

واضح جواب مزید vCPU خریدنا ہوتا۔

اگر VPS تقریباً zero steal دکھاتا اور میری application واقعی پورا ایک core استعمال کر رہی ہوتی تو upgrade مناسب ہوتا۔ لیکن observed CPU accounting کا تقریباً ایک تہائی steal تھا۔

میں اضافی virtual CPUs کے لیے اس وقت تک pay نہیں کرنا چاہتا تھا جب تک یہ نہ سمجھوں کہ پہلے vCPU کے execution time کا اتنا بڑا حصہ پہلے ہی unavailable کیوں report ہو رہا ہے۔ اس لیے میں نے VPS cancel کیا اور refund مانگا۔

AVA نے پوری رقم تیزی سے واپس کر دی

Experience کا یہ حصہ اچھا تھا۔

AVA Hosting نے پوری رقم واپس کی۔ Refund تیزی سے process ہوا اور CPU measurements پر کئی دن بحث نہیں کی گئی۔ میں نے مسئلہ بتایا، پیسے واپس مانگے، اور انہوں نے واپس کر دیے۔

میں اس کی قدر کرتا ہوں۔

اس لیے میرے experience سے دو الگ conclusions نکلتے ہیں: مجھے ملنے والے VPS میں CPU availability کا سنجیدہ مسئلہ تھا، اور AVA نے میرا refund ٹھیک طریقے سے handle کیا۔ دونوں باتیں درست ہیں۔

میں نے اس سے کیا سیکھا

اب میں VPS کو صرف 1 vCPU / 2 GB RAM / NVMe / KVM جیسی specification سے judge نہیں کرتا۔ یہ numbers بتاتے ہیں کہ کیا provision کیا گیا، یہ نہیں بتاتے کہ real workload میں CPU کتنی predictably available ہوگی۔

اب نئی VM پر میرے ابتدائی checks میں یہ شامل ہیں:

mpstat 1 60
vmstat 1 60
cat /proc/pressure/cpu
ss -ltnp
free -h
df -h
iostat -xz 1 60

AVA Hosting کے experience سے میری سب سے اہم learning یہ نہیں کہ ایک vCPU کم ہے۔ اصل بات یہ ہے کہ running process، available RAM اور بظاہر healthy disk کے نیچے بالکل مختلف مسئلہ چھپا ہو سکتا ہے۔

میرے case میں Linux نے اسے بہت واضح کر دیا:

CPU steal:    32.73%
CPU idle:      0.00%
CPU pressure: ~99%

AVA Hosting CPU resources کو بغیر sharing کے advertise کرتا ہے اور کہتا ہے کہ neighboring workload سے steal نہیں ہونا چاہیے۔ میرے VPS نے کچھ اور report کیا۔

میں نے اسے cancel کر دیا۔ AVA نے پوری رقم تیزی سے اور بغیر بحث کے واپس کر دی۔

اور اس debugging day کی کہانی وہیں ختم ہوئی۔