میں یہ تحریر REGXA کا منفی review لکھنے کے لیے نہیں کر رہا، اور نہ ہی کسی کو یہ بتانا چاہتا ہوں کہ اسے وہاں سے VPS خریدنا چاہیے یا نہیں۔ یہ صرف ایک developer کے طور پر میرے کام کا ایک دن ہے۔
میں نے 2 vCPU، 2 GB RAM اور 60 GB NVMe والے KVM VPS پر معمول کا workload منتقل کیا۔ Nginx چل رہا تھا، backend بھی چل رہا تھا۔ اس کے باوجود مشین ایسے behave کر رہی تھی جیسے شدید overload ہو: requests جمع ہو رہی تھیں، TLS operations سست ہو رہے تھے، connections کھلے رہتے تھے، اور بعض requests آخرکار HTTP 504 دینے سے پہلے دو منٹ سے زیادہ وقت لے رہی تھیں۔
CPU accounting نے investigation کی سمت بدل دی
میرا پہلا خیال واضح تھا: VPS کے اندر کوئی چیز CPU استعمال کر رہی ہے۔ پھر میں نے mpstat چلایا۔
Average CPU steal: 92.58%
CPU 0 steal: 90.62%
CPU 1 steal: 94.57%
CPU user: 4.02%
CPU system: 1.47%
CPU iowait: 0.41%
CPU idle: 0.53%انفرادی samples بار بار تقریباً 89–98% steal دکھا رہے تھے۔ CPU pressure بھی انتہائی زیادہ تھا:
CPU PSI some avg10: 79.47
CPU PSI some avg60: 75.32
CPU PSI some avg300: 76.31
Load average: 5.85 / 5.75 / 5.73یہ صرف دو vCPU والی مشین تھی۔ Linux میں runnable processes CPU کے انتظار میں تھے۔ اہم چیز عام application CPU usage نہیں بلکہ %steal تھی۔
زیادہ CPU usage اور CPU steal الگ مسائل ہیں
اگر میرا application واقعی processor استعمال کر رہا ہوتا تو میں user یا system کے بڑے اعداد دیکھنے کی توقع کرتا۔ اس کے بجائے VPS تقریباً یوں نظر آ رہا تھا:
user: 4%
system: 1%
steal: 93%CPU steal وہ وقت ہے جب virtual CPU چلنے کے لیے تیار ہو لیکن hypervisor اسے schedule نہ کرے۔ اس لیے جب میں کہتا ہوں کہ VPS سے CPU time لیا جا رہا تھا تو میرا مطلب virtualization کا یہی تکنیکی مفہوم ہے۔ میں ثابت نہیں کرسکتا کہ REGXA نے جان بوجھ کر ایسے physical cores کسی اور customer کو دے دیے جو صرف میرے لیے مخصوص تھے، اور guest metrics سے نیت ثابت نہیں ہوتی۔ میں یہ ثابت کرسکتا ہوں کہ guest کے پاس بار بار runnable work تھا لیکن اسے CPU scheduling time نہیں مل رہا تھا۔
میں نے سارا production traffic ہٹا دیا
ایک جائز اعتراض پھر بھی باقی تھا: ہوسکتا ہے workload خود مسئلہ پیدا کر رہا ہو۔ اس لیے میں نے یہ variable ختم کردیا۔ Active workload دوسری جگہ منتقل کیا، اس VPS پر production traffic روک دیا، queues خالی ہونے دیں اور وہی measurement دوبارہ کیا۔
Average CPU steal: 94.17%
CPU 0 steal: 95.56%
CPU 1 steal: 92.83%
CPU user: 1.95%
CPU system: 0.59%
CPU iowait: 0.59%
CPU idle: 2.18%نتیجہ مزید خراب ہوگیا۔ vmstat کے انفرادی samples اب بھی 91–98% steal دکھا رہے تھے، اور زیادہ سے زیادہ 15 runnable processes CPU کے انتظار میں تھے۔ اہم ترین combination یہ تھا:
user: 1.95%
system: 0.59%
steal: 94.17%میرے applications تقریباً کچھ نہیں کر رہے تھے، لیکن VM پھر بھی تقریباً پورا scheduling time کھو رہی تھی۔ معمول کا production load اب قابلِ اعتماد explanation نہیں رہا۔
localhost بھی غیرمعمولی حد تک سست ہوگیا
میں نے HTTPS کو 127.0.0.1 کے ذریعے بھی test کیا تاکہ public DNS، میرے ISP، جغرافیائی فاصلے اور external network path کو test سے نکال دیا جائے۔
Traffic کے دوران localhost HTTPS کی دس کوششوں میں سے چار TLS handshake پر fail ہوگئیں۔ کامیاب requests نے 29.30، 22.77، 12.25، 11.87، 11.12 اور 9.40 سیکنڈ لیے۔ بعض TLS handshakes اکیلے تقریباً نو سیکنڈ لیتے تھے۔
Production traffic ہٹانے کے بعد localhost بہتر ہوا، لیکن پھر بھی غیرمستحکم رہا: 0.061، 0.745، 0.830، 0.873، 1.010، 1.117، 1.121، 2.188 اور 3.355 سیکنڈ۔ وہی local operation ایک بار تقریباً 61 ms اور اگلی بار 3.3 سیکنڈ سے زیادہ لے سکتا تھا۔
باقی stack بھی نتائج دکھا رہا تھا
ایک موقع پر تقریباً 450 established connections، 122 orphaned connections، 110 FIN-WAIT-1 اور 33 CLOSE-WAIT دیکھے۔ Local backend کی listen queue تقریباً 14–15 تک اور HTTPS queue تقریباً 40 تک پہنچی۔
Nginx نے 142.857، 138.902، 135.064، 129.819 اور 128.657 سیکنڈ بعد HTTP 504 log کیے۔ دوسری requests تقریباً 67–130 سیکنڈ کھلی رہیں۔ تقریباً 35–41 سیکنڈ کے secure-connect timeouts، database network timeouts اور delayed TLS operations بھی نظر آئے۔
الگ الگ دیکھیں تو یہ Nginx، database، network یا backend کے مختلف مسائل لگ سکتے تھے۔ مگر timeout بڑھانے سے وہ CPU time پیدا نہیں ہوتا جسے hypervisor schedule ہی نہیں کر رہا۔
RAM اور disk وجہ نہیں تھے
VPS میں اب بھی تقریباً 1.0–1.1 GiB RAM available تھی، swap تقریباً استعمال نہیں ہو رہا تھا، کوئی OOM event یا OOM-killer activity نہیں تھی۔ Filesystem صرف تقریباً 20% بھرا تھا اور قریب 44 GB خالی تھا۔ اہم CPU measurements کے دوران I/O wait 1% سے کم رہا۔
Memory ختم نہیں ہوئی تھی، disk بھری نہیں تھی، اور میرے applications missing CPU استعمال نہیں کر رہے تھے۔ غالب metric اب بھی %steal تھا۔
ایک healthy KVM VPS بالکل مختلف نظر آیا
میں نے اسی قسم کی diagnosis ایک دوسرے KVM VPS پر چلائی جو معمول کا traffic serve کر رہا تھا:
Average CPU steal: 0.02%
CPU idle: 87.86%
CPU PSI avg10: 0.29
CPU PSI avg60: 0.63
CPU PSI avg300: 0.49
Load average: 0.47 / 0.33 / 0.14اس کے دس localhost HTTPS requests تقریباً 37–69 ms میں مکمل ہوئے۔ بعد میں ایک واقعی busy production VPS پر میں نے 61.71% user CPU، 5.08% system CPU، 24.09% idle اور صرف 0.13% steal دیکھا۔
اب میرے لیے یہی فرق اہم ہے۔ VPS busy اس لیے ہوسکتا ہے کہ میرا software واقعی processor استعمال کر رہا ہو۔ یہ اس guest سے بالکل مختلف حالت ہے جو measured CPU time کا 90% سے زیادہ hypervisor کے انتظار میں گزار رہا ہو۔
REGXA نے آخرکار infrastructure contention کی تصدیق کی
VM کے اندر سے میں guest کو measure کرسکتا تھا، مگر physical host، scheduler configuration، CPU quotas یا پڑوسی VMs نہیں دیکھ سکتا تھا۔ REGXA یہ دیکھ سکتی تھی۔
آخرکار support نے بتایا کہ VPS shared CPU infrastructure پر host تھا، CPU resources کئی virtual machines کے درمیان share ہوتے ہیں اور performance physical node کے load کے مطابق بدل سکتی ہے۔ انہوں نے یہ بھی بتایا کہ Frankfurt infrastructure میں خاص طور پر زیادہ demand تھی، اور میرے elevated CPU steal کو واضح طور پر resource contention on the underlying infrastructure کا نتیجہ قرار دیا۔
انہوں نے کہا کہ موجودہ infrastructure پر اس shared VPS کے CPU quotas یا scheduling policies تبدیل نہیں کیے جا سکتے اور اضافی dedicated CPU resources نہیں دیے جا سکتے۔ مجوزہ technical solution کم utilization والی location میں VPS منتقل کرنا تھا۔
یہ وضاحت اس language کے ساتھ ملانا مشکل تھا جو میں dedicated CPU cores اور guaranteed resources کے بارے میں دیکھ چکا تھا۔ میں exact host configuration نہیں دیکھ سکتا، اس لیے نہیں کہہ سکتا کہ فوری mechanism CPU overcommitment، quotas، scheduler weighting، throttling یا ان کا مجموعہ تھا۔ Intent بھی ثابت نہیں کرسکتا۔ ضرورت بھی نہیں: Linux مسلسل 92–94% steal دکھا رہا تھا، اور REGXA نے خود اسے shared infrastructure پر contention سے جوڑا۔
Refund کے لیے بھی مزید اصرار کرنا پڑا
Infrastructure کا مسئلہ واضح ہونے کے بعد میں VPS کو مختلف nodes پر منتقل کرکے مزید test نہیں کرنا چاہتا تھا۔ میں service cancel کرکے اپنے پیسے واپس چاہتا تھا۔
ابتدا میں صرف جزوی رقم کی پیشکش ہوئی، اور proposed refund میرے payment card کے بجائے REGXA account balance میں ہونا تھا۔ میرے لیے provider credit اس وقت حقیقی refund کے برابر نہیں جب میں service چھوڑنا چاہتا ہوں۔
اس لیے میں جواب دیتا رہا اور 100% payment کو original payment method پر واپس کرنے کا مطالبہ کیا۔ آخرکار REGXA نے مان لیا اور پوری رقم original payment method پر واپس کردی، جبکہ full refund کو exception قرار دیا گیا۔
میں اس بات کی قدر کرتا ہوں کہ آخر میں انہوں نے پوری رقم واپس کردی۔ لیکن support کے infrastructure contention تسلیم کرنے کے بعد بھی financial resolution کے لیے مسلسل زور دینا پڑا، اور یہ بھی میرے تجربے کا حصہ ہے۔
اس واقعے سے میرا اصول بدل گیا
سب سے آسان غلطی application کو optimize کرتے رہنا ہوتی۔ میں Nginx settings بدل سکتا تھا، timeouts بڑھا سکتا تھا، concurrency کم کرسکتا تھا، retries شامل کرسکتا تھا، MongoDB کی جانچ کرسکتا تھا یا backend code دوبارہ لکھ سکتا تھا۔ کچھ symptoms شاید بدل جاتے، لیکن اہم سوال کا جواب نہ ملتا: CPU steal 90% سے زیادہ کیوں تھا؟
اب میں صرف یہ نہیں دیکھتا کہ SSH کام کرتا ہے، Nginx start ہوتا ہے اور health endpoint 200 دیتا ہے۔ نئے VPS پر میں %user، %system، %iowait، %idle، %steal، CPU PSI، run queue اور localhost latency بھی دیکھتا ہوں۔
اور اگر کچھ مشکوک لگے تو workload ہٹاکر دوبارہ measure کرتا ہوں۔ اس واقعے میں یہی test سب سے واضح نتیجہ لایا:
CPU user: 1.95%
CPU system: 0.59%
CPU steal: 94.17%میں یہ نہیں کہتا کہ ہر REGXA VPS ایسا ہی behave کرتا ہے۔ میں نے ایک VPS test کیا اور اسی machine پر جو ہوا اسے document کیا۔ مگر اس VPS پر evidence غیرمعمولی حد تک واضح تھا: میرے applications تقریباً CPU استعمال نہیں کر رہے تھے جبکہ Linux دکھا رہا تھا کہ virtual CPU time کا بڑا حصہ hypervisor scheduling کے انتظار میں ضائع ہو رہا تھا۔ بعد میں REGXA نے اسی behavior کو shared infrastructure پر resource contention سے جوڑا۔
اسی لیے میں یہ experience document کر رہا ہوں۔ کسی score یا recommendation کے طور پر نہیں، بلکہ developer کے طور پر میری ایک عام دن کی کہانی اور ایک ایسا metric جسے میں VPS پر دوبارہ کبھی نظر انداز نہیں کروں گا۔