VPS पर CPU steal time क्या है और इसे कैसे चेक करें

CPU steal time वास्तव में क्या मापता है

CPU steal time वह समय है जब आपका virtual CPU चलने के लिए तैयार था और उसे किसी चीज़ का इंतज़ार नहीं था, लेकिन hypervisor ने physical core को किसी दूसरे guest को दे दिया था। आपका काम कतार (queue) में था। Core कहीं और व्यस्त था। Linux इन cycles को अलग से गिनता है और उन्हें st के रूप में रिपोर्ट करता है। इसी से आप यह अंतर समझ पाते हैं कि "मेरा सर्वर व्यस्त है" या "मेरा सर्वर अपनी बारी का इंतज़ार कर रहा है"।

यही अंतर इस counter के होने का मुख्य कारण है। आपकी अपनी प्रक्रियाओं द्वारा CPU पर बिताया गया समय us (user) या sy (system) के रूप में रिपोर्ट किया जाता है। storage पर blocked किसी task का समय wa (I/O wait) के रूप में रिपोर्ट होता है। एक vCPU (virtual CPU) जो runnable है, run queue में बैठा है, जिसका कोई I/O pending नहीं है, और फिर भी वह execute नहीं हो रहा है, उसे st के रूप में रिपोर्ट किया जाता है। आपके सर्वर के अंदर की कोई भी चीज़ इस स्थिति को ठीक नहीं कर सकती, क्योंकि scheduling का निर्णय आपसे एक परत नीचे, host पर लिया जाता है।

यह सीधे एक physical machine को कई guests के बीच कैसे साझा किया जाता है से संबंधित है। इसका सामान्य कारण एक पड़ोसी है: उसी node पर कोई दूसरा guest बहुत अधिक load ले रहा है, इसलिए host cores को आपके बीच विभाजित कर रहा है। एक दूसरा कारण भी है जिसे अक्सर नज़रअंदाज़ कर दिया जाता है। कई providers एक shared vCPU को physical core के एक अंश तक सीमित (cap) कर देते हैं, और कई hypervisors पर उस लागू की गई सीमा को guest के अंदर steal के रूप में गिना जाता है। इसलिए, एक उच्च st reading आपको बताती है कि core आपको नहीं दिया गया था। यह हमेशा यह नहीं बताती कि उसे किसने लिया।

Steal number कहाँ से आता है

आपका kernel स्वयं steal को नहीं माप सकता, क्योंकि वह host को नहीं देख सकता। Hypervisor उसे यह जानकारी देता है। KVM पर, host प्रत्येक vCPU के लिए एक counter को guest के साथ साझा किए गए page में लिखता है, और जब kernel को CONFIG_PARAVIRT_TIME_ACCOUNTING के साथ build किया जाता है, तो guest इसे जोड़ लेता है। हर 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। Steal, label के बाद आठवां मान है। नीचे दिए गए सभी tools, vmstat, top, mpstat और कोई भी Prometheus exporter, उसी field को पढ़ते हैं और दो samples को प्रतिशत में बदल देते हैं।

एक परिणाम बाकी सभी से अधिक महत्वपूर्ण है। यदि hypervisor कभी भी counter को export नहीं करता है, तो field हमेशा शून्य (zero) पर ही रहता है, और उस पर आधारित हर tool तब भी 0.0 की रिपोर्ट देगा जब host overloaded हो। KVM और Xen इसे export करते हैं। अन्य platforms पर, जिनमें VMware और Hyper-V शामिल हैं, steal दिखेगा या नहीं, यह इस बात पर निर्भर करता है कि host क्या expose करता है और guest kernel क्या support करता है। इसलिए, वहाँ शून्य मान अपने आप में कुछ भी साबित नहीं करता। शून्य पर भरोसा करने से पहले platform की जाँच करें:

systemd-detect-virt

यह platform का नाम print करता है, जैसे kvm, xen, vmware या microsoft, और bare metal पर none। Container के अंदर यह इसके बजाय runtime की रिपोर्ट देता है, जैसे lxc, docker या podman, जो आपको container के बारे में बताता है, न कि उसके नीचे चल रही machine के बारे में। kvm पर शून्य इस बात का वास्तविक प्रमाण है कि host आपको पर्याप्त resources दे रहा है। ऐसे platform पर जो कभी भी इस field को नहीं भरता, शून्य का कोई प्रमाण नहीं है, और ऐसी स्थिति में contention का आकलन वास्तविक काम के समय (timing) को मापकर ही किया जाना चाहिए।

VPS पर CPU steal time कैसे चेक करें?

vmstat, procps पैकेज से आता है। यह लगभग हर Ubuntu और Debian VPS इमेज में मौजूद होता है, लेकिन कुछ minimal container इमेज में नहीं होता, इसलिए इस पर निर्भर होने से पहले इसे 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। यदि यह प्रिंट होता है, तो टूल install है और आप वास्तविक kernel counters पढ़ रहे हैं। vmstat 1 5 फिर पाँच रिपोर्ट प्रिंट करता है: पहली boot के बाद का औसत है, और अगली चार एक-सेकंड के samples हैं।

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 ब्लॉक में st कॉलम ढूँढें। वर्तमान procps-ng बिल्ड KVM guest time के लिए इसके बाद एक gu कॉलम प्रिंट करते हैं, इसलिए st सबसे आखिरी के बजाय दाईं ओर से दूसरा होता है। कॉलम को उसके header नाम से पढ़ें, क्योंकि यह स्थिति releases के बीच बदलती रही है।

दो आदतें रीडिंग को सटीक रखती हैं। पहली डेटा लाइन boot के बाद का औसत है, इसलिए इसे अनदेखा करें और उसके बाद की लाइनें पढ़ें। और एक sample कोई माप नहीं है, क्योंकि steal समय-समय पर अचानक बढ़ता है: vmstat 1 61 चलाएँ, जो उस since-boot लाइन के बाद साठ एक-सेकंड के samples देता है, और कोई निष्कर्ष निकालने से पहले पूरा एक मिनट देखें।

top अपनी %Cpu(s) समरी लाइन पर वही संख्या रिपोर्ट करता है, जो 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

प्रति-कोर (per-core) विवरण के लिए, sysstat जोड़ें:

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

mpstat प्रति CPU एक रो प्रिंट करता है जिसमें %steal कॉलम होता है, जो दिखाता है कि क्या हर vCPU प्रभावित है या केवल एक। support ticket के लिए आवश्यक इतिहास हेतु, स्क्रीन से पढ़ने के बजाय samples को save करें:

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

इसे उन घंटों के दौरान cron के माध्यम से चलाएँ जिनमें आपको संदेह है, और यह फाइल प्रदाता को "पिछली रात यह धीमा लग रहा था" कहने और उन्हें सटीक दस मिनट दिखाने के बीच का अंतर बन जाती है।

Steal numbers का क्या अर्थ है?

• एक स्थिर 0.0। यह स्थिति सामान्य है, या फिर platform steal की रिपोर्ट ही नहीं दे रहा है। जश्न मनाने से पहले systemd-detect-virt के साथ इसकी पुष्टि करें।
• कुछ सेकंड के लिए कुछ प्रतिशत का उछाल। किसी भी shared node पर यह सामान्य है। हो सकता है कि किसी पड़ोसी का build शुरू हुआ हो, या host अपना backup चला रहा हो।
• Shared plan पर 1 से 5 प्रतिशत का निरंतर स्तर। यह अपेक्षित है। Shared CPU की कीमत इसी बात को दर्शाती है।
• 5 से 10 प्रतिशत का निरंतर स्तर। यह एक ऐसी मंदी है जिसे आप माप सकते हैं। प्रमाण रिकॉर्ड करना शुरू करें और कई दिनों तक एक ही समय की तुलना करें।
• एक बार में घंटों तक 10 प्रतिशत से ऊपर। या तो node आपके workload के लिए oversubscribed है या आपके plan की CPU limit लागू की जा रही है, और कुछ प्रदाता उस limit को steal के रूप में रिपोर्ट करते हैं। यह वह स्तर है जिस पर support ticket खोलना या plan बदलना उचित है।

इन श्रेणियों को एक specification के बजाय पढ़ने के दिशा-निर्देश के रूप में देखें, क्योंकि कोई भी प्रदाता shared plan पर steal की गारंटी नहीं देता है। इनका मूल्यांकन इस आधार पर करें कि आप क्या चला रहे हैं। एक रात भर चलने वाला batch job 15 प्रतिशत steal को झेल सकता है और किसी को पता भी नहीं चलेगा। Latency-sensitive service में औसत के चिंताजनक दिखने से बहुत पहले ही p99 में यह दिखाई देने लगता है, यही कारण है कि ट्रेडिंग बॉट्स जैसे latency-sensitive workloads dedicated cores पर होने चाहिए।

Steal time की लागत कितनी है?

इसका गणित संक्षिप्त है। यदि आपके 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 रीडिंग है, वह कार्य 60.0 के बजाय 61.9 सेकंड लेता है। इसके लिए कोई भी टिकट ओपन नहीं करता है। 8 प्रतिशत पर यह 65.2 सेकंड है। 40 प्रतिशत पर उसी कार्य को 100.0 सेकंड की आवश्यकता होती है, और जो कतार पहले खाली हो जाती थी, वह अब बढ़ने लगती है।

ये गणना किए गए मान हैं, माप नहीं। यह मॉडल एक एकल runnable thread और अंतराल के दौरान समान रूप से फैले हुए steal को मानता है। वास्तविक सेवाएं अक्सर इस वक्र से अधिक खराब महसूस होती हैं, क्योंकि एक stolen slice किसी request के बीच में आ जाता है और उस request पर प्रतीक्षा करने वाली हर चीज को फिर से उस देरी का भुगतान करना पड़ता है। किसी सूत्र के बजाय अपना स्वयं का आंकड़ा प्राप्त करने के लिए, शांत समय के दौरान और फिर व्यस्त समय के दौरान benchmark the VPS करें, और दोनों विंडोज़ के लिए st रिकॉर्ड करें।

क्या यह steal है, या कुछ और?

Steal को अन्य लक्षणों के साथ भ्रमित करना आसान है। counters को एक साथ, एक ही vmstat लाइन पर पढ़ें।

• st अधिक है जबकि r और us कम बने हुए हैं: host आपको core नहीं दे रहा है। यह steal है।
• r आपके vCPU count से काफी अधिक है, us उच्च है और st शून्य के करीब है: आप अपने CPUs की क्षमता से अधिक काम चला रहे हैं। r की तुलना nproc के आउटपुट से करें। यह आपकी अपनी oversubscription है, न कि किसी पड़ोसी की।
• wa उच्च है जबकि st शून्य के करीब है: tasks storage पर blocked हैं, जो एक अलग समस्या है और इसका समाधान भी अलग है।
• Load average अधिक है जबकि st और us दोनों कम हैं: load figure में uninterruptible tasks भी शामिल होते हैं, इसलिए यह आमतौर पर किसी अटके हुए device या hung network mount की ओर इशारा करता है, न कि CPU की ओर।

Burstable plans के लिए एक विशेष नोट आवश्यक है। ये आपको एक credit balance देते हैं जो आपके idle रहने पर बढ़ता है और व्यस्त रहने पर घटता है, और जब यह खत्म हो जाता है तो provider आपको baseline rate पर सीमित कर देता है। कुछ platforms पर उस throttle को steal के रूप में रिपोर्ट किया जाता है। अन्य पर यह अंदर से दिखाई नहीं देता है, और आपको बस प्रति सेकंड कम cycles मिलते हैं। यह तय करने से पहले कि कोई पड़ोसी दोषी है, plan का विवरण पढ़ें।

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

Steal एक virtual machine का गुण है, न कि उसके अंदर चल रहे कंटेनर का। आपके VPS पर चल रहा Docker कंटेनर host के /proc को साझा करता है, इसलिए इसके अंदर पढ़ा गया st मान वास्तव में उस VPS का ही steal है, जो कि आप देखना चाहते हैं। VPS के रूप में बेची जाने वाली container-based virtualisation अलग तरह से काम करती है। lxcfs के लागू होने पर, कंटेनर के अंदर का /proc/stat cgroup accounting से तैयार किया जाता है, और बनावट के अनुसार ही steal शून्य होता है। यदि monitoring stack केवल अंदर से डेटा एकत्र करता है, तो वह शून्य दिखा सकता है, जबकि नीचे की भौतिक मशीन संसाधनों की कमी से जूझ रही हो सकती है।

कंटेनर के अंदर, इसी अर्थ वाला काउंटर CPU quota throttling है। cgroup v2 पर:

cat /sys/fs/cgroup/cpu.stat

nr_throttled उन enforcement periods की गिनती करता है जिनमें group अपने CPU quota तक पहुँच गया, और throttled_usec उस कुल समय को दर्शाता है जिसके दौरान वह frozen रहा। बढ़ते हुए nr_throttled का मतलब है कि आपकी process runnable थी लेकिन चल नहीं रही थी; यह अनुभव steal के समान ही है, लेकिन यह आपके द्वारा निर्धारित सीमा के कारण होता है। होस्ट को दोष देने से पहले अपनी सीमाओं की जाँच करें, विशेषकर यदि आप अपने services को Docker में VPS पर चलाते हैं और compose file में CPU limits सेट की हैं। Layered virtualisation समय के गायब होने का एक और कारण जोड़ती है, क्योंकि आपके VPS के अंदर की VM आपके steal के साथ-साथ अपना स्वयं का scheduling delay भी जोड़ती है। यदि आप VPS पर nested virtualisation चलाते हैं तो इस बात का ध्यान रखें।

Sustained steal के मामले में क्या करें

Guest के अंदर कोई भी सेटिंग steal को ठीक नहीं कर सकती, क्योंकि निर्णय लेने वाला scheduler guest के बाहर चलता है। Kernel को अपग्रेड करने से भी यह नहीं बदलता: Linux kernel 7.2 में जोड़ा गया cache aware scheduling आपके tasks को केवल उन cores पर व्यवस्थित करता है जो आपको वास्तव में दिए गए हैं, और यह उन cycles को वापस नहीं ला सकता जो पड़ोसी (neighbour) पहले ही ले चुका है। चार कदम वास्तविक हैं।

सबसे पहले साक्ष्य एकत्र करें। UTC में timestamps, प्रत्येक episode की अवधि, इसकी पुनरावृत्ति की आवृत्ति, और यह रिकॉर्ड करें कि क्या mpstat एक vCPU को प्रभावित दिखा रहा है या सभी को। एक सप्ताह के logged samples एक स्क्रीनशॉट से अधिक मूल्यवान होते हैं।

उस डेटा के साथ एक ticket खोलें। दो सीधे प्रश्न पूछें: क्या इन windows के दौरान यह node oversubscribed है, और क्या मेरे instance को move किया जा सकता है। vmstat का output और सटीक समय paste करें। Providers एक reproducible window पर कार्रवाई करते हैं, और जो ticket केवल यह कहता है कि सर्वर धीमा है, उस पर जवाब में आपसे यही जानकारी मांगी जाएगी। आप इस काम का कितना हिस्सा सौंप सकते हैं, यह managed और unmanaged VPS के बीच के व्यावहारिक अंतरों में से एक है।

Migration के लिए कहें। Guest को कम loaded node पर ले जाना provider के लिए सामान्य काम है, और इसमें आमतौर पर एक छोटा सा reboot लगता है। यह वह समाधान है जिसकी कोई लागत नहीं है, और यह उस सामान्य स्थिति को हल करता है जहाँ एक node पर संयोगवश कई भारी neighbours एक ही समय पर मौजूद होते हैं।

Contention को खरीदकर दूर करें। एक dedicated vCPU plan आपके instance के लिए CPU capacity reserve करता है, जो provider के आधार पर एक full core या full hardware thread होता है, ताकि neighbours आपके cycles लेना बंद कर दें और counter शून्य या उसके बहुत करीब रहे। Hypervisor का अपना housekeeping अभी भी थोड़ा residue छोड़ सकता है। यह हर महीने अधिक महंगा होता है, और यह उस workload के लिए ईमानदार जवाब है जो variance को सहन नहीं कर सकता। यदि यह भी पर्याप्त नहीं है, या आप memory bandwidth भी पूरी तरह से अपने लिए चाहते हैं, तो अगला कदम VPS के बजाय dedicated server लेना है।

जब तक आप इनमें से किसी का इंतजार कर रहे हैं, तब तक steal से होने वाले नुकसान को कम करें। अपने vCPUs की संख्या से कम worker threads चलाएं, क्योंकि जो threads core प्राप्त नहीं कर सकते, वे केवल context switches को बढ़ाते हैं। Batch work को उन घंटों में ले जाएं जब node शांत होता है, जो अब आपके अपने log से पता चल रहा है। फिर उन्हीं घंटों के दौरान उसी command के साथ दोबारा मापें, ताकि आप अनुमान लगाने के बजाय यह कह सकें कि बदलाव ने काम किया या नहीं।

FAQ

VPS पर सामान्य CPU steal time क्या है?

Shared plan पर, संक्षिप्त spikes और 5 प्रतिशत से कम का निरंतर मान सामान्य है, क्योंकि shared CPU का अर्थ है कि host भौतिक cores को guests के बीच विभाजित करता है। घंटों तक दोहरे अंकों (double digits) में निरंतर मान सामान्य नहीं है और इसके लिए ticket raise करना चाहिए। Dedicated vCPU plan पर अपेक्षित मान 0.0 या उसके बहुत करीब होता है, क्योंकि hypervisor के आंतरिक कार्यों में अभी भी थोड़ा हिस्सा लग सकता है, इसलिए उससे ऊपर निरंतर steal time एक त्रुटि है जिसे रिपोर्ट किया जाना चाहिए। संख्या का आकलन अपने workload के आधार पर करें: एक overnight batch job उस steal को सहन कर सकती है जिसे latency-sensitive API नहीं कर सकता।

क्या बड़ा plan high steal time को ठीक करेगा?

केवल plan बदलने से नहीं। उसी shared node पर अधिक vCPUs का मतलब है कि अधिक virtual CPUs उन्हीं सीमित भौतिक cores के लिए प्रतिस्पर्धा कर रहे हैं, और प्रतिशत वहीं बना रह सकता है जहाँ वह था। जो चीज़ लगभग पूरी तरह से steal को हटाती है, वह है dedicated CPU allocation, या कम load वाले node पर migration। एक व्यस्त मशीन का बड़ा हिस्सा भी अंततः एक व्यस्त मशीन का ही हिस्सा होता है।

मेरा VPS 0 steal time क्यों दिखाता है जबकि यह स्पष्ट रूप से धीमा है?

इसके दो सामान्य कारण हैं। हो सकता है कि hypervisor counter को export ही न कर रहा हो, जो host और guest kernel के आधार पर कुछ platforms पर होता है, इसलिए host चाहे कुछ भी करे, यह field शून्य पर ही रहती है। यह देखने के लिए कि आप किस platform पर हैं, systemd-detect-virt चलाएँ। अन्यथा bottleneck कहीं और है: storage waits के लिए wa देखें, अपने स्वयं के overload के लिए r की तुलना nproc से करें, और quota throttling के लिए containers के अंदर /sys/fs/cgroup/cpu.stat पढ़ें।

क्या मैं अपने सर्वर के अंदर से steal time कम कर सकता हूँ?

आप guest के अंदर से host की scheduling को नहीं बदल सकते। आप केवल यह कम कर सकते हैं कि यह आपको कितना प्रभावित करता है। अपने vCPUs की संख्या से कम worker threads चलाएँ, ताकि run queue में कम काम उस core के इंतज़ार में बैठा रहे जो उपलब्ध नहीं है। Batch jobs को उन घंटों में ले जाएँ जब node पर भीड़ कम हो। परिणामों को cache करें ताकि कम requests को CPU की आवश्यकता पड़े। जो बदलाव वास्तव में steal को हटाते हैं, जैसे किसी अन्य node पर migration या dedicated cores, वे provider के अधिकार क्षेत्र में आते हैं।