VPS मधील CPU steal time आणि noisy neighbour कसे ओळखावे

CPU steal time प्रत्यक्षात काय मोजतो

CPU steal time म्हणजे तुमचा virtual CPU चालण्यासाठी तयार होता, त्याला प्रतीक्षा करण्यासारखे काहीही नव्हते, पण hypervisor ने physical core दुसऱ्या guest ला दिला त्या वेळेचा हिस्सा. काम run queue मध्ये प्रतीक्षेत होते. Core दुसरीकडे वापरला जात होता. Linux हे cycles स्वतंत्रपणे मोजते आणि st म्हणून दाखवते. त्यामुळे "माझा server व्यस्त आहे" आणि "माझा server त्याच्या turn ची प्रतीक्षा करत आहे" यांमधील फरक समजतो.

हा फरकच हा counter ठेवण्याचे मुख्य कारण आहे. तुमच्या स्वतःच्या processes ने CPU वर घालवलेला वेळ us (user) किंवा sy (system) म्हणून दाखवला जातो. एखाद्या task ने storage वर blocked अवस्थेत घालवलेला वेळ wa (I/O wait) म्हणून दाखवला जातो. I/O outstanding नसताना runnable असलेला, run queue वर प्रतीक्षेत असलेला आणि तरीही execute न होणारा vCPU (virtual CPU) st म्हणून दाखवला जातो. तुमच्या server मधील कोणतीही गोष्ट ही स्थिती दूर करू शकत नाही, कारण scheduling चा निर्णय तुमच्या स्तराच्या एक स्तर खाली, host वर घेतला जातो.

हे अनेक guests मध्ये एक physical machine कसा वाटून वापरला जातो यावरून थेट स्पष्ट होते. नेहमीचे कारण म्हणजे शेजारी guest: त्याच node वरील दुसरा guest जास्त CPU वापरत असतो, त्यामुळे host cores तुमच्यात आणि त्याच्यात वाटतो. आणखी एक कारण अनेकदा दुर्लक्षित राहते. अनेक providers shared vCPU ला physical core च्या काही अंशापुरते मर्यादित करतात. अनेक hypervisors वर ही लागू केलेली मर्यादा guest मध्ये steal म्हणून मोजली जाते. त्यामुळे st चे जास्त reading म्हणजे core तुम्हाला दिला गेला नव्हता, एवढे समजते. तो कोणी वापरला हे मात्र नेहमी समजत नाही.

Steal संख्या कुठून येते

तुमचा kernel स्वतःहून steal मोजू शकत नाही, कारण त्याला host दिसत नाही. Hypervisor ही माहिती देतो. KVM वर host प्रत्येक vCPU साठीचा counter guest सोबत shared असलेल्या page मध्ये लिहितो. kernel CONFIG_PARAVIRT_TIME_ACCOUNTING सह build केलेला असल्यास guest हा counter एकत्रित करतो. प्रत्येक distribution kernel मध्ये हे सक्षम असते. Xen हीच माहिती त्याच्या runstate area द्वारे देतो. एकूण माहिती userspace पर्यंत नेमक्या एका ठिकाणी पोहोचते:

head -1 /proc/stat

ही cpu ओळ boot पासून USER_HZ ticks मध्ये दहा counters देते. त्यांचा क्रम असा आहे: user, nice, system, idle, iowait, irq, softirq, steal, guest, guest_nice. Label नंतरची आठवी value म्हणजे steal. खालील प्रत्येक tool, vmstat, top, mpstat आणि कोणताही Prometheus exporter, हेच field वाचतो आणि दोन samples मधून percentage काढतो.

यातील एक परिणाम इतर सर्वांपेक्षा महत्त्वाचा आहे. Hypervisor ने counter export केला नाही, तर हे field कायम zero राहते. त्यावर आधारित प्रत्येक tool host overloaded असतानाही शांत 0.0 दाखवतो. KVM आणि Xen हा counter export करतात. VMware आणि Hyper-V वरील guests मध्ये सामान्यतः flat zero दिसतो. Zero वर विश्वास ठेवण्यापूर्वी platform तपासा:

systemd-detect-virt

हा command 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 पॅकेजमधून येते. हे जवळजवळ प्रत्येक Ubuntu आणि Debian VPS image मध्ये उपलब्ध असते. काही minimal container image मध्ये ते नसते. त्यामुळे त्यावर अवलंबून राहण्यापूर्वी ते 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 सारखी ओळ दाखवते. ती ओळ दिसल्यास 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 build मध्ये त्यानंतर KVM guest time साठी gu column दाखवला जातो. त्यामुळे st हा शेवटचा नसून उजवीकडून दुसरा असतो. Column header च्या नावावरून तो वाचा, कारण releases नुसार त्याचे स्थान बदलले आहे.

Reading अचूक ठेवण्यासाठी दोन सवयी उपयुक्त ठरतात. पहिली data line ही boot पासूनची सरासरी असते, त्यामुळे ती दुर्लक्षित करा आणि तिच्यानंतरच्या lines वाचा. तसेच एक sample हे measurement नसते, कारण steal bursts मध्ये येतो. निष्कर्ष काढण्यापूर्वी vmstat 1 60 चालवून पूर्ण एक मिनिट monitor करा.

top त्याच्या %Cpu(s) summary line वर तोच number दाखवते. त्या line मध्ये 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 प्रभावित आहे की फक्त एकच vCPU प्रभावित आहे हे समजते. Support ticket साठी आवश्यक असलेला history जतन करण्यासाठी samples स्क्रीनवरून वाचण्याऐवजी साठवा:

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

तुम्हाला संशय असलेल्या तासांमध्ये cron मधून ते चालवा. त्यानंतर ही file provider ला “काल रात्री ते slow वाटले” असे सांगण्याऐवजी नेमकी दहा मिनिटे दाखवण्यासाठी पुरावा देईल.

steal ची मूल्ये काय दर्शवतात?

• स्थिर 0.0. स्थिती निरोगी आहे किंवा platform steal ची नोंदच करत नाही. आनंद व्यक्त करण्यापूर्वी systemd-detect-virt ने पुष्टी करा.
• काही सेकंद टिकणारे काही टक्के spikes. कोणत्याही shared node वर हे सामान्य आहे. शेजारच्या ग्राहकाचा build सुरू होतो किंवा host त्याचे backups चालवतो.
• shared plan वर दीर्घकाळ टिकणारे 1 ते 5 percent. हे अपेक्षित आहे. किंमत shared CPU च्या वापरावर आधारित असते.
• दीर्घकाळ टिकणारे 5 ते 10 percent. मोजता येईल अशी गतीकपात. पुरावे नोंदवण्यास सुरुवात करा आणि सलग अनेक दिवसांतील समान वेळांची तुलना करा.
• एकावेळी अनेक तास 10 percent पेक्षा जास्त. तुमच्या workload साठी node वर उपलब्ध क्षमतेपेक्षा जास्त workload आहे. या पातळीवर support ticket उघडणे किंवा दुसऱ्या node वर स्थलांतर करणे योग्य ठरते.

या श्रेणींना specification ऐवजी मार्गदर्शक म्हणून वापरा, कारण कोणताही provider shared plan साठी steal ची हमी प्रकाशित करत नाही. तुम्ही चालवत असलेल्या workload च्या संदर्भात त्यांचे मूल्यांकन करा. Overnight batch job 15 percent steal सहन करू शकतो आणि कोणाच्याही लक्षात येणार नाही. Latency-sensitive service मध्ये average चिंताजनक दिसण्यापूर्वीच p99 मध्ये त्याचा परिणाम दिसतो. म्हणूनच trading bots सारखे latency-sensitive workloads dedicated cores वर ठेवणे योग्य आहे.

स्टील टाइमचा खर्च किती आहे?

हिशोब सोपा आहे. तुमच्या CPU वेळेतील s भाग घेतला गेला, तर ठरावीक CPU वेळ लागणारे काम घड्याळानुसार 1 / (1 - s) पट जास्त वेळ घेते. 60 सेकंद 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 सेकंद घेते; 60.0 सेकंद नाही. यासाठी कोणी ticket उघडत नाही. 8 टक्के असताना ते 65.2 सेकंद घेते. 40 टक्के असताना त्याच कामाला 100.0 सेकंद लागतात आणि पूर्वी रिकामी होणारी queue त्याऐवजी वाढू लागते.

ही मोजमापे नसून गणना केलेली मूल्ये आहेत. या मॉडेलमध्ये एक runnable thread आहे आणि संपूर्ण कालावधीत steal समान प्रमाणात वितरित आहे, असे गृहीत धरले आहे. प्रत्यक्ष सेवा या वक्रापेक्षा अधिक खराब परिणाम अनुभवतात. कारण steal झालेला CPU slice एखाद्या request च्या मध्यभागी येतो आणि त्या request वर अवलंबून असलेल्या प्रत्येक प्रतीक्षारत कामाला तो विलंब पुन्हा सहन करावा लागतो. सूत्राऐवजी तुमचा स्वतःचा आकडा मिळवण्यासाठी, शांत वेळेत आणि पुन्हा व्यस्त वेळेत VPS चे benchmark घ्या आणि दोन्ही कालखंडांसाठी st नोंदवा.

हे steal आहे का, की दुसरे काही?

Steal ची इतर लक्षणांशी सहज गल्लत होऊ शकते. समान vmstat ओळीवरील counters एकत्र वाचा.

• st जास्त असताना r आणि us कमी राहतात: host तुम्हाला CPU core देत नाही. हे steal आहे.
• r तुमच्या vCPU संख्येपेक्षा स्पष्टपणे जास्त असून us जास्त आणि st जवळजवळ शून्य आहे: तुमचे स्वतःचे CPUs हाताळू शकतील त्यापेक्षा जास्त काम तुम्ही चालवत आहात. r ची तुलना nproc च्या output शी करा. ही तुमची स्वतःची oversubscription आहे; शेजारच्या tenant मुळे नाही.
• wa जास्त असून st जवळजवळ शून्य आहे: tasks storage वर blocked आहेत. ही वेगळी समस्या आहे आणि तिचा उपायही वेगळा आहे.
• Load average जास्त असताना st आणि us दोन्ही कमी आहेत: load figure मध्ये uninterruptible tasks देखील मोजले जातात. त्यामुळे हे सहसा CPU ऐवजी अडकलेल्या device कडे किंवा प्रतिसाद न देणाऱ्या network mount कडे निर्देश करते.

Burstable plans साठी स्वतंत्रपणे विचार करणे आवश्यक आहे. तुम्ही idle असताना त्यामध्ये credit balance वाढतो आणि busy असताना कमी होतो. तो संपल्यावर provider तुम्हाला baseline rate वर मर्यादित ठेवतो. काही platforms वर हे throttling steal म्हणून नोंदवले जाते. इतर platforms वर ते आतून दिसत नाही आणि तुम्हाला फक्त प्रति सेकंद कमी cycles मिळतात. शेजारी जबाबदार आहे असे ठरवण्यापूर्वी plan description वाचा.

कंटेनरमध्ये steal time का दिसत नाही

Steal ही virtual machine ची वैशिष्ट्यपूर्ण बाब आहे; तिच्यामध्ये चालणाऱ्या container ची नाही. तुमच्या स्वतःच्या VPS वर चालणारा Docker container host चा /proc सामायिक करतो. त्यामुळे त्यामध्ये वाचलेले st मूल्य VPS वरील steal दर्शवते. हेच अपेक्षित आहे. VPS म्हणून विकली जाणारी container-based virtualisation वेगळ्या प्रकारे कार्य करते. lxcfs असल्यास container मधील /proc/stat हे cgroup accounting वरून तयार केले जाते. त्यामुळे steal चे मूल्य रचनेनुसार शून्य असते. केवळ container च्या आतून metrics गोळा करणारा monitoring stack, प्रत्यक्ष physical machine वरील संसाधने अपुरी असतानाही, स्थिर आणि शांत शून्य दाखवू शकतो.

Container मध्ये याच अर्थाचा counter म्हणजे CPU quota throttling. cgroup v2 वर:

cat /sys/fs/cgroup/cpu.stat

nr_throttled मध्ये group ने CPU quota गाठलेल्या enforcement periods ची संख्या मोजली जाते. throttled_usec मध्ये तो frozen अवस्थेत राहिलेला एकूण वेळ मोजला जातो. nr_throttled वाढत असल्यास तुमची process runnable होती, पण चालवली जात नव्हती. हा अनुभव steal सारखाच असतो; मात्र त्याचे कारण तुम्ही स्वतः निश्चित केलेली मर्यादा असते. Host ला दोष देण्यापूर्वी स्वतःच्या limits तपासा. विशेषतः compose file मध्ये CPU limits असलेल्या VPS वर तुम्ही Docker मध्ये तुमच्या सेवा चालवत असाल, तर हे तपासणे आवश्यक आहे. Layered virtualisation मुळे वेळ नष्ट होण्याचे आणखी एक ठिकाण निर्माण होते. कारण तुमच्या VPS मधील VM ला तुमचा steal आणि स्वतःचा scheduling delay, दोन्ही सहन करावे लागतात. तुम्ही VPS वर nested virtualisation चालवत असाल, तर हे लक्षात ठेवा.

सतत steal बद्दल काय करावे

guest मधील कोणतीही setting steal दुरुस्त करू शकत नाही, कारण हा निर्णय घेणारा scheduler guest च्या बाहेर चालतो. प्रत्यक्षात चार उपाय आहेत.

प्रथम पुरावे गोळा करा. timestamps UTC मध्ये नोंदवा. प्रत्येक episode किती काळ चालतो आणि तो किती वेळा पुन्हा होतो हे नोंदवा. तसेच mpstat मध्ये एक vCPU प्रभावित दिसतो की सर्व vCPU प्रभावित दिसतात हे तपासा. एका आठवड्याचे logged samples screenshot पेक्षा अधिक उपयुक्त असतात.

ही माहिती देऊन ticket उघडा. दोन थेट प्रश्न विचारा: या कालावधीत node वर oversubscription आहे का, आणि माझे instance दुसऱ्या node वर हलवता येईल का? vmstat चे output आणि अचूक वेळा समाविष्ट करा. पुनरुत्पादित करता येणाऱ्या कालावधीवर providers कारवाई करतात. फक्त server धीमा आहे असे लिहिलेल्या ticket ला provider त्या कालावधीची माहिती मागणारे उत्तर देतो. या कामापैकी किती भाग provider कडे सोपवता येतो, हा managed आणि unmanaged VPS मधील एक व्यावहारिक फरक आहे.

migration मागा. guest ला कमी loaded node वर हलवणे हे provider साठी नियमित काम आहे. यासाठी सहसा थोडा reboot लागतो. या उपायासाठी अतिरिक्त खर्च होत नाही. एकाच node वर एकाच वेळी अनेक heavy neighbours असण्याच्या सामान्य परिस्थितीत हा उपाय समस्या सोडवतो.

contention टाळण्यासाठी अधिक खर्चाचा पर्याय घ्या. dedicated vCPU plan तुमच्या instance साठी physical cores राखून ठेवतो. त्यामुळे counter zero वर राहतो. यासाठी दरमहा अधिक खर्च येतो. variance सहन न करू शकणाऱ्या workload साठी हा योग्य उपाय आहे. तरीही ते पुरेसे नसेल, किंवा memory bandwidth देखील फक्त तुमच्यासाठी हवी असेल, तर पुढील पर्याय म्हणजे VPS ऐवजी dedicated server घेणे.

यापैकी कोणताही उपाय होईपर्यंत steal मुळे होणारा परिणाम कमी करा. तुमच्याकडे जितके vCPU आहेत त्यापेक्षा कमी worker threads चालवा, कारण core मिळू न शकणारे threads केवळ context switches वाढवतात. node शांत असतो त्या वेळेत batch work चालवा. आता तुमचा log ही वेळ दाखवतो. त्यानंतर त्याच command ने आणि त्याच वेळांमध्ये पुन्हा measurement घ्या. त्यामुळे अंदाज न लावता बदलाचा परिणाम झाला की नाही हे सांगता येईल.

FAQ

VPS वरील सामान्य CPU steal time किती असतो?

Shared plan मध्ये थोड्या वेळासाठी होणारे spikes आणि सुमारे 5 टक्क्यांपेक्षा कमी असलेली सततची value सामान्य आहे. याचे कारण म्हणजे shared CPU मध्ये host भौतिक cores वेगवेगळ्या guests मध्ये विभागतो. अनेक तास सतत double digits असणे सामान्य नाही आणि त्यासाठी support ticket उघडणे योग्य आहे. Dedicated vCPU plan मध्ये अपेक्षित reading 0.0 असते. त्यामुळे त्यापेक्षा वेगळी value आढळल्यास fault report करा. ही संख्या तुमच्या स्वतःच्या workload च्या संदर्भात तपासा. Latency-sensitive API च्या तुलनेत overnight batch job अधिक steal time सहन करू शकते.

मोठा plan घेतल्याने high steal time ची समस्या सुटेल का?

स्वतःहून नाही. त्याच shared node वर अधिक vCPUs घेतल्यास त्याच मर्यादित physical cores साठी स्पर्धा करणारे virtual CPUs वाढतात. त्यामुळे percentage जशी होती तशीच राहू शकते. Dedicated CPU allocation किंवा कमी load असलेल्या node वर migration केल्याने steal time कमी होते. व्यस्त 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 यांची तुलना करा. Containers मधील quota throttling साठी /sys/fs/cgroup/cpu.stat वाचा.

माझ्या server मधून steal time कमी करता येतो का?

Guest मधून host चे scheduling बदलता येत नाही. त्याचा परिणाम किती होतो हे मात्र कमी करता येते. तुमच्याकडे जितके vCPUs आहेत त्यापेक्षा कमी worker threads चालवा. त्यामुळे उपलब्ध नसलेल्या core ची वाट पाहत run queue वर कमी काम साचेल. Node वर कमी load असलेल्या वेळेत batch jobs चालवा. Results cache करा, म्हणजे CPU ची गरज असलेल्या requests ची संख्या कमी होईल. Steal time प्रत्यक्षात कमी करणारे बदल, म्हणजे दुसऱ्या node वर migration किंवा dedicated cores, provider च्या बाजूने करावे लागतात.