VPS میں CPU steal time اور noisy neighbour کی پہچان

CPU steal time دراصل کیا ناپتا ہے

CPU steal time اس وقت کے حصے کو ناپتا ہے جب آپ کا virtual CPU چلنے کے لیے تیار تھا، اسے کسی چیز کا انتظار نہیں تھا، لیکن hypervisor نے physical core کسی دوسرے guest کو دے دیا۔ کام queue میں موجود تھا۔ core کسی اور guest کے پاس تھا۔ Linux ان cycles کو الگ شمار کرتا ہے اور انہیں st کے طور پر رپورٹ کرتا ہے۔ اس سے معلوم ہوتا ہے کہ "میرا server مصروف ہے" یا "میرا server اپنی باری کا انتظار کر رہا ہے"۔

اسی فرق کی وجہ سے یہ counter موجود ہے۔ آپ کے اپنے processes نے CPU پر جتنا وقت گزارا، وہ us (user) یا sy (system) کے طور پر رپورٹ ہوتا ہے۔ کسی task نے storage پر blocked رہ کر جتنا وقت گزارا، وہ wa (I/O wait) کے طور پر رپورٹ ہوتا ہے۔ جو vCPU (virtual CPU) runnable ہو، run queue میں موجود ہو، جس کی کوئی I/O زیر التوا نہ ہو، لیکن پھر بھی execute نہ ہو رہا ہو، اسے st کے طور پر رپورٹ کیا جاتا ہے۔ آپ کے server کے اندر کوئی چیز اس state کو ختم نہیں کر سکتی، کیونکہ scheduling کا فیصلہ آپ سے ایک سطح نیچے، host پر ہوتا ہے۔

یہ براہ راست یہ سمجھنے سے متعلق ہے کہ VPS ایک physical machine کو کیسے share کرتا ہے اور اسے متعدد guests کے درمیان تقسیم کرتا ہے۔ عام وجہ کوئی neighbour ہوتا ہے: اسی node پر موجود کوئی دوسرا guest بہت زیادہ CPU استعمال کر رہا ہوتا ہے، اس لیے host cores آپ کے اور اس guest کے درمیان تقسیم کرتا ہے۔ ایک دوسری وجہ بھی ہے جسے اکثر نظر انداز کر دیا جاتا ہے۔ بہت سے providers shared vCPU کو physical core کے ایک حصے تک محدود رکھتے ہیں، اور کئی hypervisors میں اس نافذ کردہ حد کو guest کے اندر steal کے طور پر account کیا جاتا ہے۔ اس لیے st کی بلند reading بتاتی ہے کہ core آپ کو نہیں دیا گیا۔ یہ ہمیشہ نہیں بتاتی کہ اسے کس نے لے رکھا تھا۔

Steal کا نمبر کہاں سے آتا ہے

آپ کا kernel خود steal time کی پیمائش نہیں کر سکتا، کیونکہ اسے host نظر نہیں آتا۔ یہ معلومات hypervisor فراہم کرتا ہے۔ KVM میں host ہر vCPU کا counter guest کے ساتھ مشترکہ page میں لکھتا ہے، اور جب kernel کو CONFIG_PARAVIRT_TIME_ACCOUNTING کے ساتھ build کیا جاتا ہے تو guest اس counter کو جمع کرتا ہے۔ ہر distribution kernel میں یہ شامل ہوتا ہے۔ Xen اپنی runstate area کے ذریعے یہی معلومات فراہم کرتا ہے۔ یہ مجموعہ userspace تک صرف ایک جگہ پہنچتا ہے:

head -1 /proc/stat

یہ cpu لائن دس counters فراہم کرتی ہے۔ یہ boot کے بعد سے USER_HZ ticks میں ہوتے ہیں اور ان کی ترتیب یہ ہے: user، nice، system، idle، iowait، irq، softirq، steal، guest، guest_nice۔ label کے بعد آٹھویں value steal ہوتی ہے۔ ذیل کے تمام tools، یعنی vmstat، top، mpstat اور Prometheus exporter، اسی field کو پڑھتے ہیں اور دو samples کو percentage میں تبدیل کرتے ہیں۔

ایک نتیجہ باقی سب سے زیادہ اہم ہے۔ اگر hypervisor یہ counter کبھی export نہ کرے تو field ہمیشہ zero رہتی ہے، اور اس پر مبنی ہر tool ایک پرسکون 0.0 دکھاتا ہے، حالانکہ host پر بہت زیادہ load ہو سکتا ہے۔ KVM اور Xen یہ counter export کرتے ہیں۔ VMware اور Hyper-V پر چلنے والے guests عموماً مسلسل zero رپورٹ کرتے ہیں۔ Zero پر اعتماد کرنے سے پہلے platform چیک کریں:

systemd-detect-virt

یہ platform کا نام دکھاتا ہے، مثلاً kvm، xen، vmware یا microsoft، جبکہ bare metal پر none دکھاتا ہے۔ Container کے اندر یہ اس کے بجائے runtime رپورٹ کرتا ہے، مثلاً lxc، docker یا podman۔ اس سے container کے بارے میں معلومات ملتی ہیں، نیچے موجود machine کے بارے میں نہیں۔ kvm پر zero اس بات کا حقیقی ثبوت ہے کہ host آپ کے workload کو مناسب CPU وقت دے رہا ہے۔ جس platform پر یہ field کبھی پُر ہی نہ ہوتی ہو، وہاں zero کسی بات کا ثبوت نہیں ہوتا۔ ایسی صورت میں contention کا اندازہ حقیقی کام کی timing ناپ کر لگانا ہوتا ہے۔

VPS پر CPU steal time کیسے چیک کریں؟

vmstat، procps پیکیج کا حصہ ہے۔ یہ تقریباً ہر Ubuntu اور Debian VPS image میں موجود ہوتا ہے، لیکن کچھ minimal container images میں موجود نہیں ہوتا۔ اس لیے اس پر انحصار کرنے سے پہلے اسے install کریں۔

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

vmstat --version ایک ایسی لائن دکھاتا ہے جیسے vmstat from procps-ng 4.0.4۔ اگر یہ output ظاہر ہو تو tool install ہے اور آپ kernel کے حقیقی counters پڑھ رہے ہیں۔ اس کے بعد vmstat 1 5 ہر سیکنڈ میں ایک sample لیتا ہے، کل پانچ مرتبہ۔

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

دائیں جانب موجود cpu block میں st column تلاش کریں۔ موجودہ procps-ng builds اس کے بعد KVM guest time کے لیے gu column دکھاتے ہیں، اس لیے st دائیں طرف سے دوسرا column ہوتا ہے، آخری نہیں۔ Column کو اس کے header name سے پڑھیں، کیونکہ releases کے درمیان اس کی position تبدیل ہو چکی ہے۔

درست نتیجے کے لیے دو باتوں کا خیال رکھیں۔ پہلی data line boot کے بعد سے اب تک کی average ہوتی ہے، اس لیے اسے نظرانداز کریں اور اس کے بعد والی lines پڑھیں۔ ایک sample measurement نہیں ہوتا، کیونکہ steal bursts میں آتا ہے۔ نتیجہ اخذ کرنے سے پہلے vmstat 1 60 چلائیں اور پورے ایک منٹ تک monitor کریں۔

top اپنی %Cpu(s) summary line پر یہی number report کرتا ہے، جس میں field 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

ہر core کی تفصیل کے لیے sysstat شامل کریں:

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

mpstat ہر CPU کے لیے ایک row دکھاتا ہے، جس میں %steal column شامل ہوتا ہے۔ اس سے معلوم ہوتا ہے کہ ہر vCPU متاثر ہے یا صرف ایک۔ Support ticket کے لیے درکار history حاصل کرنے کے لیے samples کو screen سے پڑھنے کے بجائے محفوظ کریں:

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

اس command کو مشتبہ اوقات کے دوران cron سے چلائیں۔ اس طرح file provider کو یہ کہنے اور عین دس منٹ کا ثبوت دکھانے کے درمیان فرق پیدا کرے گی کہ "گزشتہ رات system سست محسوس ہو رہا تھا۔"

steal numbers سے کیا مراد ہے؟

• مسلسل 0.0۔ صحت مند حالت، یا platform بالکل steal رپورٹ نہیں کرتا۔ خوش ہونے سے پہلے systemd-detect-virt سے تصدیق کریں۔
• چند سیکنڈ تک چند فیصد کے spikes۔ کسی بھی shared node پر معمول کی بات ہے۔ کسی دوسرے صارف کا build شروع ہو سکتا ہے، یا host اپنے backups چلا سکتا ہے۔
• shared plan پر مسلسل 1 سے 5 فیصد۔ متوقع ہے۔ قیمت shared CPU کے استعمال کی عکاسی کرتی ہے۔
• مسلسل 5 سے 10 فیصد۔ قابلِ پیمائش سست روی ہے۔ شواہد ریکارڈ کرنا شروع کریں اور کئی دنوں میں انہی اوقات کا تقابل کریں۔
• ایک وقت میں کئی گھنٹوں تک 10 فیصد سے زیادہ۔ node آپ کے workload کے لیے oversubscribed ہے۔ یہ وہ سطح ہے جس پر support ticket کھولنا یا دوسرے node پر منتقل ہونا مناسب ہے۔

ان حدود کو specification کے بجائے رہنما اصول سمجھیں، کیونکہ کوئی provider shared plan پر steal کی ضمانت شائع نہیں کرتا۔ انہیں اپنے workload کے تناظر میں جانچیں۔ رات بھر چلنے والا batch job 15 فیصد steal برداشت کر سکتا ہے اور کسی کو محسوس بھی نہیں ہوتا۔ latency-sensitive service میں average تشویش ناک ہونے سے بہت پہلے p99 میں اثر ظاہر ہو جاتا ہے۔ اسی لیے trading bots جیسے latency-sensitive workloads کو dedicated cores پر چلانا چاہیے۔

steal time کی لاگت کتنی ہے؟

حساب مختصر ہے۔ اگر آپ کے CPU وقت کا s حصہ لے لیا جائے تو مقررہ مقدار میں CPU وقت درکار کرنے والا کام clock کے حساب سے 1 / (1 - s) گنا زیادہ وقت لیتا ہے۔ 60 seconds کا 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 فیصد پر، جو عام shared-plan صورتحال ہے، یہ کام 61.9 seconds کے بجائے 60.0 seconds لیتا ہے۔ اس پر کوئی ticket نہیں کھولتا۔ 8 فیصد پر یہ وقت 65.2 seconds ہو جاتا ہے۔ 40 فیصد پر اسی کام کو 100.0 seconds درکار ہوتے ہیں، اور جو queue پہلے خالی ہو جاتی تھی وہ اس کے بجائے بڑھنے لگتی ہے۔

یہ calculated values ہیں، measurements نہیں۔ اس model میں ایک runnable thread فرض کیا گیا ہے اور یہ فرض کیا گیا ہے کہ پورے interval میں steal یکساں طور پر تقسیم ہے۔ حقیقی services اکثر اس curve سے زیادہ متاثر ہوتی ہیں، کیونکہ stolen slice کسی request کے درمیان آتا ہے اور اس تاخیر کی قیمت اس request کا انتظار کرنے والی ہر چیز کو دوبارہ ادا کرنا پڑتی ہے۔ formula کے بجائے اپنی قدر معلوم کرنے کے لیے، VPS کا benchmark لیں، پہلے ایک پُرسکون hour میں اور پھر مصروف hour میں، اور دونوں windows کے لیے st record کریں۔

کیا یہ steal ہے، یا کوئی اور مسئلہ؟

steal کو دیگر symptoms کے ساتھ آسانی سے خلط ملط کیا جا سکتا ہے۔ اسی vmstat line پر counters کو ایک ساتھ دیکھیں۔

• st زیادہ ہو، جبکہ r اور us کم رہیں: host آپ کو CPU core نہیں دے رہا۔ یہ steal ہے۔
• r آپ کے vCPU count سے خاصا زیادہ ہو، us زیادہ ہو، اور st تقریباً صفر ہو: آپ اپنے CPUs کی گنجائش سے زیادہ کام چلا رہے ہیں۔ r کا موازنہ nproc کے output سے کریں۔ یہ آپ کی اپنی oversubscription ہے، کسی پڑوسی instance کا مسئلہ نہیں۔
• wa زیادہ ہو اور st تقریباً صفر ہو: tasks storage پر blocked ہیں۔ یہ الگ مسئلہ ہے اور اس کا حل بھی مختلف ہے۔
• Load average زیادہ ہو، جبکہ st اور us دونوں کم ہوں: load figure میں uninterruptible tasks بھی شامل ہوتے ہیں۔ اس لیے عموماً مسئلہ CPU کے بجائے کسی stuck device یا hung network mount کی طرف اشارہ کرتا ہے۔

Burstable plans کے لیے الگ وضاحت ضروری ہے۔ جب آپ idle ہوتے ہیں تو ان میں credit balance بنتا ہے، اور مصروف ہونے پر کم ہوتا ہے۔ credit balance ختم ہونے کے بعد provider آپ کو baseline rate تک محدود کر دیتا ہے۔ کچھ platforms پر یہ throttle steal کے طور پر رپورٹ ہوتا ہے۔ دوسرے platforms پر یہ اندر سے نظر نہیں آتا، اور آپ کو صرف فی سیکنڈ کم cycles ملتے ہیں۔ کسی پڑوسی کو ذمہ دار قرار دینے سے پہلے plan description پڑھیں۔

کنٹینر میں steal time کیوں رپورٹ نہیں ہوتا

Steal ورچوئل مشین کی خاصیت ہے، اس کے اندر چلنے والے کنٹینر کی نہیں۔ آپ کے اپنے VPS میں Docker کنٹینر میزبان کا /proc شیئر کرتا ہے، اس لیے اس کے اندر پڑھی جانے والی st قدر VPS کا steal ہوتی ہے، اور یہی مطلوبہ نتیجہ ہے۔ VPS کے طور پر فروخت کی جانے والی container-based virtualisation مختلف انداز میں کام کرتی ہے۔ جب lxcfs موجود ہو تو کنٹینر کے اندر /proc/stat کو cgroup accounting سے اخذ کیا جاتا ہے، اور ساختی طور پر steal صفر رہتا ہے۔ اگر monitoring stack صرف کنٹینر کے اندر سے metrics حاصل کرے تو وہ نیچے موجود physical machine کے وسائل ختم ہونے کے باوجود مسلسل صفر دکھا سکتا ہے۔

کنٹینر کے اندر وہ counter جو یہی مفہوم رکھتا ہے، CPU quota throttling ہے۔ cgroup v2 میں:

cat /sys/fs/cgroup/cpu.stat

nr_throttled ان enforcement periods کی تعداد شمار کرتا ہے جن میں group اپنی CPU quota تک پہنچا، جبکہ throttled_usec اس وقت کا مجموعہ ہے جس دوران group منجمد رہا۔ nr_throttled میں اضافہ اس بات کی علامت ہے کہ آپ کا process چلنے کے قابل تھا لیکن اسے CPU نہیں ملی۔ یہ تجربہ steal جیسا ہے، مگر اس کی وجہ وہ limit ہے جو آپ نے خود مقرر کی ہے۔ میزبان کو ذمہ دار ٹھہرانے سے پہلے اپنی limits چیک کریں، خاص طور پر اگر آپ VPS پر Docker میں اپنی services چلاتے ہیں اور compose file میں CPU limits مقرر ہیں۔ Layered virtualisation میں وقت ضائع ہونے کی ایک اور جگہ شامل ہو جاتی ہے، کیونکہ آپ کے VPS کے اندر چلنے والی VM کو آپ کا steal اور اپنی scheduling delay، دونوں برداشت کرنا پڑتے ہیں۔ اگر آپ VPS پر nested virtualisation چلاتے ہیں تو اس بات کو مدنظر رکھیں۔

مسلسل steal سے نمٹنے کے لیے کیا کریں

guest کے اندر کوئی setting، steal کو درست نہیں کر سکتی، کیونکہ فیصلہ کرنے والا scheduler guest کے باہر چلتا ہے۔ kernel کو upgrade کرنے سے بھی یہ نہیں بدلتا۔ Linux kernel 7.2 میں شامل cache-aware scheduling آپ کے tasks کو صرف ان cores کے درمیان دوبارہ تقسیم کرتی ہے جو حقیقت میں آپ کو دیے گئے ہیں، اور وہ cycles واپس حاصل نہیں کر سکتی جو کوئی پڑوسی پہلے ہی لے چکا ہو۔ چار عملی اقدامات ہیں۔

پہلے شواہد جمع کریں۔ UTC میں timestamps، ہر episode کا دورانیہ، اس کے repeat ہونے کی frequency، اور یہ ریکارڈ کریں کہ آیا mpstat ایک vCPU کو متاثر کرتا ہے یا سب کو۔ ایک ہفتے کے logged samples کی قدر screenshot سے زیادہ ہوتی ہے۔

اس data کے ساتھ ticket کھولیں۔ دو براہِ راست سوال پوچھیں: کیا ان اوقات کے دوران یہ node oversubscribed ہے، اور کیا میری instance کو منتقل کیا جا سکتا ہے؟ vmstat کا output اور درست اوقات شامل کریں۔ Providers قابلِ تکرار window کی بنیاد پر کارروائی کرتے ہیں۔ صرف یہ لکھنے پر کہ server slow ہے، ticket کے جواب میں عموماً ایک مخصوص window مانگی جاتی ہے۔ اس کام کا کتنا حصہ آپ provider کو سونپ سکتے ہیں، یہ managed اور unmanaged VPS کے درمیان عملی فرقوں میں سے ایک ہے۔

Migration کی درخواست کریں۔ guest کو کم loaded node پر منتقل کرنا provider کے لیے معمول کا کام ہے، اور عموماً اس کے لیے مختصر reboot درکار ہوتا ہے۔ یہ ایسا fix ہے جس کی کوئی اضافی لاگت نہیں، اور عام صورتِ حال حل کر دیتا ہے، جب ایک node پر اتفاقاً ایک ہی وقت میں کئی heavy neighbours موجود ہوں۔

Contention ختم کرنے کے لیے خریداری کریں۔ dedicated vCPU plan آپ کی instance کے لیے physical cores reserve کرتا ہے، اس لیے counter صفر پر رہتا ہے۔ اس کی ماہانہ لاگت زیادہ ہوتی ہے، لیکن ایسے workload کے لیے یہی درست جواب ہے جو اس variance کو برداشت نہیں کر سکتا۔ اگر یہ بھی کافی نہ ہو، یا آپ memory bandwidth بھی صرف اپنے لیے چاہتے ہوں، تو اگلا قدم VPS کے بجائے dedicated server ہے۔

جب تک ان میں سے کوئی اقدام نہیں ہوتا، steal کے نقصان کو کم کریں۔ اپنے vCPUs کی تعداد سے کم worker threads چلائیں، کیونکہ ایسے threads جو core حاصل نہیں کر سکتے، صرف context switches میں اضافہ کرتے ہیں۔ Batch work کو ان اوقات میں منتقل کریں جب node کم مصروف ہو؛ اب آپ کا اپنا log یہ اوقات بتا سکتا ہے۔ پھر اسی command سے انہی hours کے دوران دوبارہ measurement کریں، تاکہ اندازے کے بجائے واضح طور پر بتا سکیں کہ تبدیلی مؤثر رہی یا نہیں۔

FAQ

VPS پر معمول کا CPU steal time کتنا ہوتا ہے؟

Shared plan میں مختصر spikes اور تقریباً 5 percent سے کم مسلسل value معمول کی بات ہیں، کیونکہ shared CPU میں host physical cores کو مختلف guests کے درمیان تقسیم کرتا ہے۔ کئی گھنٹوں تک مسلسل double digits معمول کی بات نہیں؛ اس کے لیے support ticket بنانا چاہیے۔ Dedicated vCPU plan پر متوقع reading 0.0 ہے، اس لیے وہاں کوئی بھی دوسری value report کرنے کے قابل fault ہے۔ اس number کو اپنے workload کے مطابق جانچیں: overnight batch job اتنا steal برداشت کر سکتی ہے جسے latency-sensitive API برداشت نہیں کر سکتی۔

کیا بڑا plan زیادہ steal time کا مسئلہ حل کر دے گا؟

صرف اس سے نہیں۔ اسی shared node پر زیادہ vCPUs کا مطلب ہے کہ زیادہ virtual CPUs انہی contended physical cores کے لیے مقابلہ کریں گی، اور percentage بالکل وہی رہ سکتی ہے۔ Steal کو ختم کرنے کے لیے dedicated CPU allocation یا کم load والے node پر migration درکار ہے۔ مصروف machine کا بڑا حصہ بھی مصروف machine ہی کا حصہ ہوتا ہے۔

میری VPS واضح طور پر slow ہونے کے باوجود 0 steal time کیوں دکھاتی ہے؟

اس کی دو عام وجوہات ہیں۔ Hypervisor یہ counter بالکل export نہ کرتا ہو، جو VMware اور Hyper-V platforms پر عام ہے؛ اس لیے host کچھ بھی کرے، field zero رہتی ہے۔ Run systemd-detect-virt تاکہ معلوم ہو کہ آپ کون سا platform استعمال کر رہے ہیں۔ بصورت دیگر bottleneck کہیں اور ہے: storage waits کے لیے wa چیک کریں، اپنے workload کے overload کے لیے r کا nproc سے موازنہ کریں، اور quota throttling کے لیے containers کے اندر /sys/fs/cgroup/cpu.stat پڑھیں۔

کیا میں اپنے server کے اندر سے steal time کم کر سکتا ہوں؟

آپ guest کے اندر سے host کی scheduling تبدیل نہیں کر سکتے۔ آپ صرف اس کے اثرات کم کر سکتے ہیں۔ اپنے vCPUs کی تعداد سے کم worker threads چلائیں، تاکہ run queue پر اس core کے انتظار میں کم work پڑا رہے جو دستیاب نہیں ہو رہا۔ Batch jobs کو ان اوقات میں منتقل کریں جب node کم مصروف ہو۔ Results کو cache کریں تاکہ کم requests کو CPU درکار ہو۔ Steal کو واقعی ختم کرنے والی تبدیلیاں، یعنی دوسرے node پر migration یا dedicated cores، provider کی جانب سے ہی کی جا سکتی ہیں۔