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 आपली पाळी येण्याची प्रतीक्षा करत आहे” यांमधील फरक समजतो.

हा 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 मधील कोणतीही गोष्ट ही स्थिती दूर करू शकत नाही, कारण scheduling चा निर्णय तुमच्या स्तराखाली, host वर घेतला जातो.

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

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

तुमचा kernel स्वतःहून steal मोजू शकत नाही, कारण त्याला host दिसत नाही. Hypervisor ही माहिती देतो. KVM वर host प्रत्येक vCPU साठीचा counter guest सोबत shared असलेल्या page मध्ये लिहितो. kernel CONFIG_PARAVIRT_TIME_ACCOUNTING सह build केलेला असल्यास guest हे मूल्य एकत्र करतो. सर्व distribution kernel मध्ये CONFIG_PARAVIRT_TIME_ACCOUNTING असते. 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 नंतर 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 वरील guest मध्ये सामान्यतः कायम 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 म्हणजे कोणताही पुरावा नाही. अशा वेळी प्रत्यक्ष कामाच्या timing वरून 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 name पाहून column वाचा, कारण releases नुसार त्याचे स्थान बदलले आहे.

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

top त्याच summary line वर, %Cpu(s) मध्ये, st ने दर्शविलेल्या field मध्ये तोच आकडा दाखवते:

%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 साठी आवश्यक असलेला इतिहास जतन करण्यासाठी samples screen वरून वाचण्याऐवजी ते जतन करा:

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

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

steal चे आकडे काय दर्शवतात?

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

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

तुमच्यासाठी steal time ची किंमत किती?

ही गणना थोडक्यात करता येते. तुमच्या CPU वेळेतील 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 टक्के steal time हा सामान्य shared-plan reading आहे. या स्थितीत job ला 61.9 seconds लागतात, 60.0 seconds ऐवजी. यासाठी कोणी ticket उघडत नाही. 8 टक्क्यांवर हा वेळ 65.2 seconds होतो. 40 टक्क्यांवर त्याच job ला 100.0 seconds लागतात. पूर्वी रिकामी होणारी queue वाढू लागते.

ही calculated values आहेत, measurements नाहीत. या model मध्ये एकच runnable thread आहे आणि संपूर्ण interval मध्ये steal time समान प्रमाणात पसरलेला आहे असे गृहीत धरले आहे. प्रत्यक्ष services ला हा परिणाम curve पेक्षा अधिक गंभीर जाणवतो. कारण stolen slice एखाद्या request च्या मध्यभागी येतो. त्यानंतर त्या request ची वाट पाहणाऱ्या प्रत्येक घटकाला तो delay पुन्हा सहन करावा लागतो. Formula ऐवजी तुमचा स्वतःचा आकडा मिळवण्यासाठी, शांत वेळेत आणि पुन्हा व्यस्त वेळेत VPS चे benchmark घ्या आणि दोन्ही windows साठी st नोंदवा.

हे steal आहे की आणखी काही?

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

• st जास्त असताना r आणि us कमी राहतात: host तुम्हाला CPU core देत नाही. हे steal आहे.
• तुमच्या vCPU संख्येपेक्षा r लक्षणीयरीत्या जास्त आहे, 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 वर ही throttle स्थिती steal म्हणून नोंदवली जाते. इतर platforms वर ती आतून दिसत नाही आणि तुम्हाला फक्त प्रति सेकंद कमी cycles मिळतात. शेजारी tenant कारणीभूत आहे असे ठरवण्यापूर्वी plan description वाचा.

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

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

कंटेनरमध्ये समान अर्थ दर्शवणारा counter म्हणजे CPU quota throttling. cgroup v2 वर:

cat /sys/fs/cgroup/cpu.stat

nr_throttled मध्ये group ने CPU quota गाठलेल्या enforcement periods ची संख्या मोजली जाते. throttled_usec मध्ये तो throttled राहिलेला एकूण वेळ मोजला जातो. nr_throttled वाढत असल्यास तुमची process runnable होती, परंतु चालत नव्हती. हा अनुभव steal सारखाच आहे, मात्र त्याचे कारण तुम्ही स्वतः लागू केलेली मर्यादा आहे. Host ला दोष देण्यापूर्वी स्वतःच्या मर्यादा तपासा. विशेषतः compose file मध्ये CPU limits देऊन तुम्ही VPS वर Docker मध्ये तुमच्या सेवा चालवत असल्यास हे तपासणे महत्त्वाचे आहे. 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 तुम्हाला प्रत्यक्षात दिलेल्या cores वर तुमची tasks पुन्हा मांडते; शेजारील guest ने आधीच घेतलेले cycles ते परत मिळवू शकत नाही. यासाठी चार प्रत्यक्ष उपाय आहेत.

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

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

Migration मागा. guest कमी load असलेल्या node वर हलवणे हे provider साठी नेहमीचे काम आहे आणि त्यासाठी सहसा अल्प reboot आवश्यक असतो. या उपायासाठी अतिरिक्त खर्च होत नाही. एकाच node वर एकाच वेळी अनेक heavy neighbours असण्याची सामान्य समस्या यामुळे सुटते.

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

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

FAQ

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

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

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

केवळ त्याने समस्या सुटत नाही. त्याच shared node वर अधिक vCPUs घेतल्यास त्याच व्यस्त physical cores साठी स्पर्धा करणारे virtual CPUs वाढतात आणि टक्केवारी पूर्वीसारखीच राहू शकते. Steal time कमी करण्यासाठी dedicated CPU allocation किंवा कमी लोड असलेल्या node वर migration आवश्यक आहे. व्यस्त मशीनमधील मोठा वाटा म्हणजे तरीही व्यस्त मशीनमधीलच वाटा असतो.

माझा VPS स्पष्टपणे slow असताना steal time 0 का दाखवतो?

याची दोन सामान्य कारणे आहेत. 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 चे output तपासा.

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

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