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 लाइन दस counters को, boot के बाद से USER_HZ ticks में, इस क्रम में दर्शाती है: user, nice, system, idle, iowait, irq, softirq, steal, guest, guest_nice। Steal लेबल के बाद आठवां मान है। नीचे दिए गए सभी tools, vmstat, top, mpstat और कोई भी Prometheus exporter, उसी field को पढ़ते हैं और दो samples को प्रतिशत में बदल देते हैं।

एक परिणाम बाकी सभी से अधिक महत्वपूर्ण है। यदि hypervisor कभी भी counter export नहीं करता है, तो field हमेशा शून्य पर रहता है, और उस पर आधारित हर tool तब भी शांत 0.0 रिपोर्ट करता है जब host overloaded होता है। KVM और Xen इसे export करते हैं। VMware और Hyper-V पर चलने वाले guests आमतौर पर शून्य रिपोर्ट करते हैं। शून्य पर भरोसा करने से पहले platform की जाँच करें:

systemd-detect-virt

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

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

vmstat, procps पैकेज से आता है। यह लगभग हर Ubuntu और Debian VPS इमेज में मौजूद होता है, लेकिन कुछ minimal container इमेज में नहीं होता, इसलिए इस पर निर्भर होने से पहले इसे इंस्टॉल कर लें।

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

vmstat --version, vmstat from procps-ng 4.0.4 जैसी एक लाइन प्रिंट करता है। यदि यह प्रिंट होता है, तो टूल इंस्टॉल है और आप वास्तविक kernel counters पढ़ रहे हैं। vmstat 1 5 फिर प्रति सेकंड एक सैंपल, पांच बार लेता है।

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 अंतिम के बजाय दाईं ओर से दूसरा होता है। कॉलम को उसके हेडर नाम से पढ़ें, क्योंकि releases के बीच इसकी स्थिति बदलती रहती है।

दो आदतें रीडिंग को सटीक रखती हैं। पहली डेटा लाइन बूट के बाद का औसत होती है, इसलिए इसे अनदेखा करें और उसके बाद की लाइनें पढ़ें। और एक सैंपल मापन नहीं है, क्योंकि steal bursts में आता है: vmstat 1 60 चलाएं और कोई निष्कर्ष निकालने से पहले पूरा एक मिनट देखें।

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

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

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

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

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

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

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

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

इन श्रेणियों को एक गाइड के रूप में देखें, न कि किसी विनिर्देश (specification) के रूप में, क्योंकि कोई भी प्रदाता shared plan पर steal की गारंटी नहीं देता है। इन्हें अपने द्वारा चलाए जा रहे कार्यों के आधार पर तौलें। एक overnight batch job 15 प्रतिशत steal को झेल सकती है और किसी को पता भी नहीं चलेगा। एक latency-sensitive service में यह औसत के चिंताजनक दिखने से बहुत पहले p99 में दिखाई देने लगता है, यही कारण है कि latency-sensitive workloads जैसे कि trading bots को 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 चलाते हैं तो इस बात का ध्यान रखें।

लगातार होने वाले steal के बारे में क्या करें

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

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

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

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

contention को पैसे देकर खत्म करें। एक dedicated vCPU plan आपके instance के लिए physical cores को आरक्षित करता है, इसलिए counter शून्य पर रहता है। इसकी मासिक लागत अधिक है, और यह उस 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) में निरंतर मान सामान्य नहीं है और इसके लिए support ticket बनाना उचित है। Dedicated vCPU plan पर अपेक्षित मान 0.0 है, इसलिए वहां कुछ भी अलग होना एक ऐसी खराबी है जिसकी रिपोर्ट की जानी चाहिए। इस संख्या का आकलन अपने workload के आधार पर करें: एक रात भर चलने वाला batch job उस steal को सोख सकता है जिसे latency-sensitive API नहीं झेल सकता।

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

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

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

इसके दो सामान्य कारण हैं। Hypervisor शायद counter को export ही न करता हो, जो VMware और Hyper-V 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 के अधिकार क्षेत्र में आते हैं।