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

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

CPU steal time اس وقت کے حصے کو ظاہر کرتا ہے جب آپ کا virtual CPU چلنے کے لیے تیار تھا، اسے کسی چیز کا انتظار نہیں تھا، لیکن hypervisor نے physical core کسی دوسرے guest کو دے دیا۔ کام run 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 کا فیصلہ آپ سے ایک layer نیچے host پر کیا جاتا ہے۔

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

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

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

head -1 /proc/stat

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

ایک نتیجہ باقی تمام باتوں سے زیادہ اہم ہے۔ اگر hypervisor یہ counter کبھی export نہ کرے تو field ہمیشہ zero رہتی ہے، اور اس پر مبنی ہر tool پرسکون 0.0 رپورٹ کرتا رہتا ہے، جبکہ host پر زیادہ load ہو سکتا ہے۔ KVM اور Xen اسے 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 آپ کو مناسب وسائل دے رہا ہے۔ جس platform پر یہ field کبھی پُر ہی نہ ہوتی ہو، وہاں zero کسی بات کا ثبوت نہیں ہے، اور contention کا اندازہ حقیقی کام کے وقت کی پیمائش سے لگانا ہوگا۔

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

vmstat، procps package کا حصہ ہے۔ یہ تقریباً ہر 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 ایسی سطر print کرتا ہے جیسے vmstat from procps-ng 4.0.4۔ اگر یہ print ہو جائے تو tool install ہے اور آپ kernel کے حقیقی counters پڑھ رہے ہیں۔ vmstat 1 5 اس کے بعد ہر second میں ایک 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 print کرتے ہیں، اس لیے st آخری کے بجائے دائیں طرف سے دوسرا column ہے۔ Column کو اس کے header name سے پڑھیں، کیونکہ releases کے درمیان اس کی پوزیشن تبدیل ہو چکی ہے۔

دو عادتیں reading کو درست رکھتی ہیں۔ پہلی data line boot کے بعد سے اب تک کی average ہوتی ہے، اس لیے اسے نظرانداز کریں اور اس کے بعد والی lines پڑھیں۔ ایک sample measurement نہیں ہوتا، کیونکہ steal وقفے وقفے سے آتا ہے۔ نتیجہ اخذ کرنے سے پہلے vmstat 1 60 چلائیں اور پورے minute تک اسے 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 print کرتا ہے، جس میں %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 کو یہ بتانے اور exact دس minutes کا ثبوت دکھانے کے درمیان فرق بن جاتی ہے کہ "گزشتہ رات رفتار کم محسوس ہوئی تھی"۔

steal اعداد کا کیا مطلب ہے؟

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

ان حدود کو 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 time کا s حصہ لے لیا جائے، تو مقررہ CPU وقت درکار ہونے والا job گھڑی کے حساب سے 1 / (1 - s) گنا زیادہ وقت لیتا ہے۔ 60 seconds کا CPU وقت درکار ہونے والے job کے لیے:

[
  {
    "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 percent کی شرح، جو عام shared-plan صورتحال میں دیکھی جا سکتی ہے، پر یہ job 61.9 seconds لیتا ہے، جبکہ پہلے 60.0 seconds لگتے تھے۔ اس پر کوئی ticket نہیں کھولتا۔ 8 percent پر یہ وقت 65.2 seconds ہو جاتا ہے۔ 40 percent پر اسی job کو 100.0 seconds درکار ہوتے ہیں، اور جو queue پہلے خالی ہو جاتی تھی وہ اس کے بجائے بڑھنے لگتی ہے۔

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

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

steal کو دوسری علامات کے ساتھ الجھانا آسان ہے۔ اسی vmstat لائن پر موجود counters کو ایک ساتھ پڑھیں۔

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

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

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

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

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

cat /sys/fs/cgroup/cpu.stat

nr_throttled ان enforcement periods کی تعداد گنتا ہے جن میں group نے اپنا CPU quota پورا کر لیا، جبکہ throttled_usec اس وقت کا مجموعہ ہے جس دوران group frozen رہا۔ nr_throttled میں اضافہ اس بات کی نشاندہی کرتا ہے کہ آپ کا process runnable تھا لیکن چل نہیں رہا تھا۔ یہ 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 کے باہر چلتا ہے۔ صرف چار اقدامات مؤثر ہیں۔

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

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

migration کی درخواست کریں۔ guest کو کم load والے node پر منتقل کرنا provider کے لیے معمول کا کام ہے، اور عموماً اس کے لیے مختصر reboot درکار ہوتا ہے۔ یہ ایسا حل ہے جس کی کوئی اضافی لاگت نہیں، اور یہ عام صورتِ حال حل کر دیتا ہے جس میں ایک 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 سے انہی اوقات کے دوران دوبارہ measurement کریں، تاکہ اندازہ لگانے کے بجائے واضح طور پر بتا سکیں کہ تبدیلی مؤثر ہوئی یا نہیں۔

FAQ

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

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

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

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

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

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

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

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