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

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

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

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

यह सीधे एक VPS कई guests के बीच एक physical machine को कैसे साझा करता है से संबंधित है। इसका सामान्य कारण एक पड़ोसी है: उसी 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 kernels में यह सुविधा होती है। Xen भी अपने runstate area के माध्यम से यही जानकारी देता है। यह कुल योग userspace में केवल एक स्थान पर पहुँचता है:

head -1 /proc/stat

वह cpu लाइन दस counters को बूट के बाद से 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 का नाम print करता है, जैसे kvm, xen, vmware या microsoft, और bare metal पर none। Container के अंदर यह इसके बजाय runtime की रिपोर्ट देता है, जैसे lxc, docker या podman, जो आपको container के बारे में बताता है, न कि उसके नीचे की मशीन के बारे में। kvm पर शून्य इस बात का वास्तविक प्रमाण है कि host आपको अच्छी सेवा दे रहा है। ऐसे 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 जैसी एक लाइन print करता है। यदि यह print होता है, तो 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 ब्लॉक में st कॉलम खोजें। वर्तमान procps-ng builds में KVM guest time के लिए इसके बाद एक gu कॉलम print होता है, इसलिए st अंतिम के बजाय दाईं ओर से दूसरा होता है। कॉलम को उसके header नाम से पढ़ें, क्योंकि releases के बीच इसकी स्थिति बदलती रही है।

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

top अपनी %Cpu(s) summary लाइन पर, 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

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

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

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

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

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

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 या migration को उचित ठहराता है।

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

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

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

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

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

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

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

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

कंटेनर के अंदर, जो काउंटर समान अर्थ रखता है वह CPU quota throttling है। cgroup v2 पर:

cat /sys/fs/cgroup/cpu.stat

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

लगातार steal होने पर क्या करें

Guest के भीतर कोई भी सेटिंग steal को ठीक नहीं कर सकती, क्योंकि निर्णय लेने वाला scheduler guest के बाहर चलता है। चार कदम वास्तविक समाधान हैं।

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

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

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

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 के आधार पर करें: एक overnight 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 के अधिकार क्षेत्र में आते हैं।