वर्चुअल CPU समय कौन चुरा रहा है?

हाय! इस लेख में, मैं यह बताना चाहता हूं कि आम आदमी की चोरी में, वीएम में चोरी कैसे दिखाई देती है और आपको कुछ कम स्पष्ट कलाकृतियों के बारे में बताती है, जो हमें उस विषय पर शोध के दौरान मिलीं, जिसमें मैं मेल के सीटीओ के रूप में शामिल था । कॉम बादल समाधान मंच। मंच केवीएम चलाता है।

सीपीयू चोरी का समय वह समय है जिसके दौरान एक वीएम संचालित करने के लिए आवश्यक संसाधन प्राप्त नहीं करता है। यह समय केवल वर्चुअलाइजेशन वातावरण में एक अतिथि ओएस में गणना की जा सकती है। यह बेहद अस्पष्ट है कि जहां आवंटित संसाधन खो गए हैं, वास्तविक जीवन की स्थितियों की तरह। हालांकि, हमने इसका पता लगाने का फैसला किया, और हमने ऐसा करने के लिए कई परीक्षणों का प्रदर्शन भी किया। यह कहना नहीं है कि हम चोरी के बारे में सब कुछ जानते हैं , लेकिन कुछ आकर्षक चीजें हैं जो हम आपके साथ साझा करना चाहते हैं।

1. चोरी क्या है?

चोरी एक मीट्रिक है जो वीएम प्रक्रियाओं के लिए सीपीयू समय की कमी को इंगित करता है। जैसा कि केवीएम कर्नेल पैच में वर्णित है, चोरी वह समय है जब एक हाइपरविजर होस्ट ओएस में अन्य प्रक्रियाओं को चलाने में खर्च करता है, जबकि वीएम प्रक्रिया एक रन कतार में होती है। दूसरे शब्दों में, चोरी की गणना उस क्षण के बीच के अंतर के रूप में की जाती है जब कोई प्रक्रिया चलाने के लिए तैयार होती है और उस समय जब सीपीयू समय को प्रक्रिया के लिए आवंटित किया जाता है।

VM कर्नेल को हाइपरविजर से चोरी की मीट्रिक मिलती है। हाइपरविजर निर्दिष्ट नहीं करता है कि कौन सी प्रक्रिया चल रही है। यह सिर्फ कहता है: "मैं व्यस्त हूं, और आपको कोई समय आवंटित नहीं कर सकता।" KVM में, चोरी की गणना पैच में समर्थित है। इसके संबंध में दो मुख्य बिंदु हैं:

• एक VM हाइपरविजर से चोरी के बारे में सीखता है। इसका मतलब यह है कि नुकसान के संदर्भ में, चोरी एक अप्रत्यक्ष माप है जिसे कई तरीकों से विकृत किया जा सकता है।
  
• हाइपरवाइजर वीएम सूचना के साथ साझा नहीं करता है कि उसके पास क्या है। सबसे महत्वपूर्ण बात यह है कि यह इसके लिए समय आवंटित नहीं करता है। इसलिए, VM स्वयं चोरी मीट्रिक में विकृतियों का पता नहीं लगा सकता है , जिसका अनुमान प्रतिस्पर्धा की प्रक्रियाओं की प्रकृति से लगाया जा सकता है।
  

2. चोरी को क्या प्रभावित करता है?

2.1। चोरी की गणना

अनिवार्य रूप से, चोरी की गणना सीपीयू के उपयोग के समय की तरह कम या ज्यादा की जाती है। उपयोग की गणना कैसे की जाती है, इस बारे में बहुत अधिक जानकारी नहीं है। ऐसा शायद इसलिए है क्योंकि अधिकांश पेशेवर यह स्पष्ट समझते हैं। हालांकि, कुछ नुकसान भी हैं। प्रक्रिया ब्रेंडन ग्रेग के एक लेख में वर्णित है। वह उपयोग और परिदृश्यों की गणना करने के तरीके के बारे में बारीकियों की एक पूरी मेजबानी पर चर्चा करता है जिसमें गणना गलत होगी:

• सीपीयू ओवरहीटिंग और थ्रोटलिंग।
  
• टर्बो बूस्ट को चालू / बंद करना, जिसके परिणामस्वरूप सीपीयू क्लॉक रेट में बदलाव होता है।
• सीपीयू बिजली-बचत प्रौद्योगिकियों, जैसे स्पीडस्टेप, का उपयोग करने पर होने वाला समय टुकड़ा परिवर्तन होता है।
  
• औसत गणना से संबंधित समस्याएं: 80% बिजली पर एक मिनट के लिए उपयोग को मापने से एक अल्पकालिक 100% वृद्धि छिपाई जा सकती है।
  
• एक स्पिनलॉक जिसके परिणामस्वरूप प्रोसेसर का उपयोग किया जाता है, लेकिन उपयोगकर्ता प्रक्रिया प्रगति नहीं करती है। परिणामस्वरूप, परिकलित CPU उपयोग 100% होगा, लेकिन प्रक्रिया वास्तव में CPU समय का उपभोग नहीं करेगी।
  

मैं चोरी की ऐसी गणनाओं का वर्णन करने वाले किसी भी लेख पर नहीं आया हूं (यदि आप किसी को जानते हैं, तो कृपया उन्हें टिप्पणी अनुभाग में साझा करें)। जैसा कि आप स्रोत कोड से देख सकते हैं, गणना तंत्र उपयोग के लिए समान है। अंतर केवल इतना है कि एक और काउंटर केवीएम प्रक्रिया (वीएम प्रक्रिया) के लिए विशेष रूप से जोड़ा जाता है, जो गणना करता है कि केवीएम प्रक्रिया सीपीयू समय की प्रतीक्षा कर रही है। काउंटर अपने विनिर्देश से सीपीयू पर डेटा लेता है और जांचता है कि क्या वीएम प्रक्रिया द्वारा उसके सभी टिक्स का उपयोग किया जा रहा है। यदि सभी टिक का उपयोग किया जा रहा है, तो सीपीयू केवल वीएम प्रक्रिया में व्यस्त था। अन्यथा, हम जानते हैं कि सीपीयू कुछ और कर रहा था और चोरी प्रतीत होती है।

जिस प्रक्रिया से चोरी की गणना की जाती है वह उसी मुद्दों के अधीन होती है जो उपयोग की नियमित गणना के रूप में होती है। ये मुद्दे इतने सामान्य नहीं हैं, लेकिन वे भ्रामक दिख सकते हैं।

2.2। KVM वर्चुअलाइजेशन के प्रकार

सामान्य तौर पर, तीन प्रकार के वर्चुअलाइजेशन होते हैं, और वे सभी केवीएम द्वारा समर्थित होते हैं। वह तंत्र जिसके द्वारा चोरी होती है, वर्चुअलाइजेशन के प्रकार पर निर्भर हो सकता है।

अनुवाद। इस स्थिति में, VM OS निम्न तरीके से भौतिक हाइपरविजर उपकरणों के साथ काम करेगा:

1. गेस्ट OS अपने गेस्ट डिवाइस को कमांड भेजता है।
   
2. अतिथि डिवाइस ड्राइवर कमांड को स्वीकार करता है, एक BIOS डिवाइस अनुरोध बनाता है, और कमांड को हाइपरवाइज़र को भेजता है।
   
3. हाइपरविजर प्रक्रिया एक भौतिक उपकरण कमांड में कमांड का अनुवाद करती है, जिससे यह अन्य चीजों के बीच अधिक सुरक्षित हो जाता है।
   
4. भौतिक डिवाइस ड्राइवर संशोधित आदेश को स्वीकार करता है और इसे भौतिक डिवाइस को अग्रेषित करता है।
   
5. कमांड का निष्पादन परिणाम उसी पथ का अनुसरण करता है।
   

अनुवाद का लाभ यह है कि यह हमें किसी भी उपकरण का अनुकरण करने की अनुमति देता है और ओएस कर्नेल की कोई विशेष तैयारी की आवश्यकता नहीं होती है। लेकिन यह प्रदर्शन की कीमत पर आता है।

हार्डवेयर वर्चुअलाइजेशन। इस स्थिति में, एक डिवाइस हार्डवेयर स्तर पर ओएस से कमांड प्राप्त करता है। यह सबसे तेज और समग्र सर्वोत्तम विधि है। दुर्भाग्य से, सभी भौतिक उपकरण, हाइपरविजर और अतिथि ओएस इसका समर्थन नहीं करते हैं। अभी के लिए, हार्डवेयर वर्चुअलाइजेशन का समर्थन करने वाले मुख्य उपकरण सीपीयू हैं।

पैरावर्चुअलाइजेशन। KVM पर डिवाइस वर्चुअलाइजेशन के लिए सबसे आम विकल्प और अतिथि OS के लिए सबसे व्यापक प्रकार का वर्चुअलाइजेशन है। इसकी मुख्य विशेषता यह है कि यह कुछ हाइपरविजर सबसिस्टम (जैसे नेटवर्क या ड्राइव स्टैक) के साथ काम करता है और निम्न-स्तरीय कमांडों का अनुवाद किए बिना हाइपरविजर एपीआई का उपयोग करके मेमोरी पेज आवंटित करता है। इस वर्चुअलाइजेशन विधि का नुकसान अतिथि ओएस के कर्नेल को संशोधित करने की आवश्यकता है जो एक ही एपीआई का उपयोग करके हाइपरविजर के साथ बातचीत करने की अनुमति देता है। इस समस्या का सबसे आम समाधान है विशिष्ट ड्राइवर को अतिथि ओएस में स्थापित करना। केवीएम में इस एपीआई को एक गुण एपीआई कहा जाता है।

जब paravirtualization का उपयोग किया जाता है, तो भौतिक डिवाइस का पथ उन मामलों की तुलना में बहुत छोटा होता है, जब अनुवाद का उपयोग किया जाता है, क्योंकि कमांड को सीधे VM से होस्ट में हाइपरवाइजर प्रक्रिया में भेजा जाता है। यह वीएम के भीतर सभी निर्देशों के निष्पादन में तेजी लाता है। KVM में, इसके लिए एक virtio API जिम्मेदार है। यह केवल कुछ उपकरणों जैसे नेटवर्क और ड्राइव एडेप्टर के लिए काम करता है। यही कारण है कि गुणियो ड्राइवरों को वीएम पर स्थापित किया जाता है।

इस तरह के त्वरण का दूसरा पहलू यह है कि एक वीएम में सभी प्रक्रियाएं वीएम के भीतर नहीं रहती हैं। इसके परिणामस्वरूप कई प्रभाव हुए, जिससे चोरी हो सकती है। यदि आप अधिक जानना चाहते हैं, तो वर्चुअल I / O: virtio के लिए An API से शुरू करें।

2.3। उचित समय निर्धारण

एक हाइपरविजर पर एक वीएम वास्तव में, एक नियमित प्रक्रिया है, जो एक लिनक्स कर्नेल में शेड्यूलिंग कानूनों (प्रक्रियाओं के बीच संसाधन वितरण) के अधीन है। आइए इस पर करीब से नज़र डालते हैं।

लिनक्स तथाकथित CFS, पूरी तरह से उचित समयबद्धक का उपयोग करता है, जो कर्नेल 2.6.23 के साथ डिफ़ॉल्ट हो गया। इस एल्गोरिथ्म पर एक हैंडल पाने के लिए, लिनक्स कर्नेल आर्किटेक्चर या स्रोत कोड पढ़ें। सीएफएस का सार प्रक्रियाओं के बीच सीपीयू समय के वितरण में निहित है, उनके रन समय के आधार पर। एक प्रक्रिया के लिए जितना अधिक CPU समय की आवश्यकता होती है, उतना कम CPU समय मिलता है। यह सभी प्रक्रियाओं के "निष्पक्ष" निष्पादन की गारंटी देता है और सभी प्रोसेसरों में से एक को लेने से बचने में मदद करता है, सभी समय और अन्य प्रक्रियाओं को भी चलाने की अनुमति देता है।

कभी-कभी इस प्रतिमान का परिणाम दिलचस्प कलाकृतियों में होता है। लंबे समय तक चलने वाले लिनक्स उपयोगकर्ताओं को यह याद नहीं होगा कि संकलक जैसे संसाधन-गहन अनुप्रयोगों को चलाने पर डेस्कटॉप पर एक नियमित पाठ संपादक कैसे स्थिर हो जाएगा। ऐसा इसलिए हुआ क्योंकि संसाधन-प्रकाश कार्य, जैसे कि डेस्कटॉप अनुप्रयोग, ऐसे कार्यों से प्रतिस्पर्धा कर रहे थे जो संकलक की तरह कई संसाधनों का उपयोग करते थे। सीएफएस इसे अनुचित मानता है, और इसलिए यह समय-समय पर पाठ संपादक को रोकता है और सीपीयू को संकलक कार्यों को संसाधित करने देता है। यह शेड्यूल_ऑटोग्रुप तंत्र का उपयोग करके तय किया गया था; हालांकि, सीपीयू समय वितरण के कई अन्य लक्षण हैं। यह लेख वास्तव में सीएफएस कितना बुरा है के बारे में नहीं है। यह इस तथ्य पर ध्यान आकर्षित करने का एक प्रयास है कि सीपीयू समय का "निष्पक्ष" वितरण सबसे तुच्छ कार्य नहीं है।

एक अनुसूचक का दूसरा महत्वपूर्ण पहलू पूर्व-भुगतान है। यह किसी भी अति-प्रेरित प्रक्रियाओं के सीपीयू से छुटकारा पाने और दूसरों को भी काम करने की अनुमति देने के लिए आवश्यक है। इसे संदर्भ स्विचिंग कहा जाता है । पूरे कार्य प्रसंग को बरकरार रखा जाता है: स्टैक की स्थिति, रजिस्टर, और इसी तरह, जिसके बाद प्रक्रिया को प्रतीक्षा करने के लिए छोड़ दिया जाता है और इसे दूसरी प्रक्रिया से बदल दिया जाता है। यह एक ओएस के लिए एक महंगा ऑपरेशन है। यह शायद ही कभी इस्तेमाल किया जाता है, लेकिन यह वास्तव में बिल्कुल भी बुरा नहीं है। बार-बार संदर्भ स्विच करना OS समस्या का एक संकेतक हो सकता है लेकिन यह आमतौर पर लगातार होता है और विशेष रूप से किसी भी मुद्दे का संकेत नहीं है।

एक तथ्य को समझाने के लिए यह लंबा प्रवचन आवश्यक था: एक निष्पक्ष लिनक्स शेड्यूलर में, सीपीयू संसाधन जितना अधिक होता है, उतनी ही तेजी से इसे अन्य प्रक्रियाओं को काम करने की अनुमति देने के लिए रोक दिया जाएगा। यह सही है या नहीं यह एक जटिल सवाल है, और समाधान लोड के आधार पर अलग है। हाल तक तक, विंडोज अनुसूचक ने डेस्कटॉप अनुप्रयोगों को प्राथमिकता दी, जिसके परिणामस्वरूप धीमी पृष्ठभूमि की प्रक्रियाएं हुईं। सन सोलारिस में पांच अलग-अलग अनुसूचक वर्ग थे। जब वर्चुअलाइजेशन शुरू किया गया था, तो उन्होंने एक और एक, फेयर शेयर शेड्यूलर जोड़ा, क्योंकि अन्य सोलारिस ज़ोन्स वर्चुअलाइज़ेशन के साथ ठीक से नहीं चल रहे थे। इसमें गहराई से खुदाई करने के लिए, मैं सोलारिस इंटर्नल: सोलारिस 10 और ओपनसोलारिस कर्नेल आर्किटेक्चर या लिनक्स कर्नेल को समझना शुरू करने की सलाह देता हूं।

2.4। हम चोरी की निगरानी कैसे कर सकते हैं?

किसी भी अन्य सीपीयू मीट्रिक की तरह, यह एक वीएम के अंदर चोरी की निगरानी करना आसान है। आप किसी भी सीपीयू मीट्रिक माप उपकरण का उपयोग कर सकते हैं। मुख्य बात यह है कि वीएम लिनक्स पर होना चाहिए। किसी कारण से, Windows उपयोगकर्ता को ऐसी जानकारी प्रदान नहीं करता है। :(


शीर्ष आउटपुट: सही कॉलम में चोरी के साथ सीपीयू लोड का विनिर्देश

हाइपरविजर से यह जानकारी प्राप्त करने की कोशिश करते समय चीजें जटिल हो जाती हैं। आप उदाहरण के लिए, लोड औसत (एलए) का उपयोग करके एक मेजबान मशीन पर चोरी का पूर्वानुमान लगाने की कोशिश कर सकते हैं। रन क्यू में प्रक्रियाओं की संख्या का औसत मूल्य है। इस पैरामीटर के लिए गणना विधि एक सरल नहीं है, लेकिन सामान्य तौर पर, अगर एक ला जिसे सीपीयू थ्रेड्स की संख्या के अनुसार मानकीकृत किया गया है, तो यह 1 से अधिक है, इसका मतलब है कि लिनक्स सर्वर अतिभारित है।

तो, इन सभी प्रक्रियाओं का क्या इंतजार है? जाहिर है, सी.पी.यू. हालांकि, यह उत्तर काफी सटीक नहीं है, क्योंकि कभी-कभी सीपीयू मुक्त होता है और एलए बहुत अधिक होता है। याद रखें कि एनएफएस गिरता है और एलए उसी समय बढ़ जाता है । इसी तरह की स्थिति ड्राइव और अन्य इनपुट / आउटपुट डिवाइस के साथ हो सकती है। वास्तव में, प्रक्रियाएं लॉक के अंत की प्रतीक्षा कर सकती हैं: भौतिक (इनपुट / आउटपुट उपकरणों से संबंधित) या तार्किक (उदाहरण के लिए एक म्यूटेक्स ऑब्जेक्ट)। हार्डवेयर स्तर के ताले (उदाहरण के लिए, डिस्क प्रतिक्रिया) या तर्क-स्तर के ताले (तथाकथित "लॉकिंग प्रिमिटिव") के लिए भी यही सच है, जिसमें कई संस्थाएं, म्यूटेक्स एडेप्टिव और स्पिन, सेमाफोरस, कंडीशन वैरिएबल, आरडब्ल्यू लॉक, शामिल हैं। ipc ताले ...)।

एलए की एक और विशेषता यह है कि यह ओएस के भीतर औसत मूल्य के रूप में गणना की जाती है। उदाहरण के लिए, यदि 100 प्रक्रियाएं एक फ़ाइल के लिए प्रतिस्पर्धा करती हैं, तो एलए 50 है। यह बड़ी संख्या में ऐसा लग सकता है कि यह ओएस के लिए खराब है। हालांकि, खराब लिखित कोड के लिए यह सामान्य हो सकता है। केवल वह विशिष्ट कोड खराब होगा, और शेष OS ठीक हो सकता है।

इस औसत (एक मिनट से भी कम समय) के कारण, एलए का उपयोग करके कुछ भी निर्धारित करना सबसे अच्छा विचार नहीं है, क्योंकि यह कुछ उदाहरणों में बेहद अस्पष्ट परिणाम दे सकता है। यदि आप इसके बारे में अधिक जानने की कोशिश करते हैं, तो आप पाएंगे कि विकिपीडिया और अन्य उपलब्ध संसाधन केवल मामलों के सबसे सरल का वर्णन करते हैं, और इस प्रक्रिया का विस्तार से वर्णन नहीं किया गया है। यदि आप इस में रुचि रखते हैं, फिर से, ब्रेंडन ग्रेग पर जाएं और लिंक का पालन करें।

3. विशेष प्रभाव

आइए अब चोरी के मुख्य मामलों के बारे में जानें जो हमने सामना किए। मुझे यह समझाने की अनुमति दें कि वे ऊपर से कैसे परिणाम देते हैं और वे हाइपरवाइजर मीट्रिक के साथ कैसे संबंध रखते हैं।

Overutilization। सबसे सरल और सबसे सामान्य मामला: हाइपरविजर को अतिव्यापी किया जा रहा है। वास्तव में, बहुत सारे वीएम चलने और सीपीयू संसाधनों का उपभोग करने के साथ, प्रतिस्पर्धा अधिक है, और एलए के अनुसार उपयोग 1 से अधिक है (सीपीयू थ्रेड्स के अनुसार मानकीकृत)। सब कुछ सभी वीएम के भीतर रहता है। हाइपरवाइजर से भेजी गई चोरी भी बढ़ती है। आपको लोड को फिर से विभाजित करना होगा या कुछ बंद करना होगा। कुल मिलाकर, यह सब तार्किक और सीधा है।

Paravirtualization बनाम एकल उदाहरण। हाइपरविजर पर केवल एक वीएम है। वीएम इसका एक छोटा हिस्सा खाता है, लेकिन उच्च इनपुट / आउटपुट लोड प्रदान करता है, उदाहरण के लिए, एक ड्राइव के लिए। अप्रत्याशित रूप से, 10% से कम की एक छोटी चोरी दिखाई देती है (जैसा कि हमने परीक्षण किए कुछ परीक्षण)।

यह एक जिज्ञासु मामला है। इधर, paravirtualized उपकरणों के स्तर पर ताले के कारण चोरी दिखाई देती है। वीएम के अंदर, एक ब्रेकपॉइंट बनाया जाता है। यह ड्राइवर द्वारा संसाधित किया जाता है और हाइपरविज़र में जाता है। हाइपरविजर पर ब्रेकपॉइंट प्रसंस्करण के कारण, वीएम इसे भेजे गए अनुरोध के रूप में देखता है। यह चलाने के लिए तैयार है और सीपीयू की प्रतीक्षा कर रहा है, लेकिन सीपीयू समय नहीं मिलता है। VM सोचता है कि समय चुरा लिया गया है।

यह तब होता है जब बफ़र भेजा जाता है। यह हाइपरविजर के कर्नेल स्थान पर जाता है और हम इसका इंतजार करते हैं। वीएम के दृष्टिकोण से, इसे तुरंत वापस आना चाहिए। इसलिए, हमारी चोरी गणना एल्गोरिदम के अनुसार, इस समय को चोरी माना जाता है। यह संभावना है कि अन्य तंत्र इसमें शामिल हो सकते हैं (जैसे अन्य एसआईएस कॉल का प्रसंस्करण), लेकिन वे किसी भी महत्वपूर्ण डिग्री से भिन्न नहीं होना चाहिए।

शेड्यूलर बनाम अत्यधिक लोड VMs। जब एक वीएम दूसरों की तुलना में अधिक चोरी करता है, तो यह सीधे अनुसूचक से जुड़ा होता है। जितना अधिक लोड एक प्रक्रिया सीपीयू पर डालता है, उतनी ही तेजी से एक अनुसूचक इसे बाहर निकाल देगा, ताकि अन्य प्रक्रियाओं को काम करने की अनुमति मिल सके। यदि वीएम कम खपत कर रहा है, तो यह लगभग कोई चोरी का अनुभव नहीं करेगा । इसकी प्रक्रिया अभी बैठी हुई है और प्रतीक्षा कर रही है, और इसे और अधिक समय दिए जाने की आवश्यकता है। यदि VM सभी कोर पर अधिकतम लोड डालता है, तो प्रक्रिया को अधिक बार फेंक दिया जाता है और VM को कम समय दिया जाता है।

जब वीएम अधिक सीपीयू प्राप्त करने की कोशिश करता है, तो यह और भी बदतर होता है, क्योंकि वे डेटा को संसाधित नहीं कर सकते हैं। फिर हाइपरविजर पर ओएस उचित अनुकूलन के कारण कम सीपीयू समय प्रदान करेगा। यह प्रक्रिया स्नोबॉल करती है, और आसमान को ऊंचा उठाती है, जबकि अन्य वीएम इसे नोटिस भी नहीं कर सकते हैं। जितने अधिक कोर हैं, दुर्भाग्यपूर्ण वीएम के लिए उतना ही बुरा है। संक्षेप में, कई कोर के साथ अत्यधिक भरी हुई VM सबसे अधिक पीड़ित हैं।

लो ला लेकिन चोरी मौजूद है। यदि एलए लगभग 0.7 है (जिसका अर्थ है कि हाइपरवाइजर को कम भार लगता है), लेकिन कुछ वीएम में चोरी होती है:

• उपर्युक्त paravirtualization उदाहरण लागू होता है। VM को ऐसे मेट्रिक्स प्राप्त हो सकते हैं जो चोरी का संकेत देते हैं, जबकि हाइपरवाइजर के पास कोई समस्या नहीं है। हमारे परीक्षणों के परिणामों के अनुसार, इस तरह की चोरी 10% से अधिक नहीं होती है और वीएम के भीतर आवेदन प्रदर्शन पर महत्वपूर्ण प्रभाव नहीं पड़ता है।
  
• LA पैरामीटर की गणना गलत तरीके से की गई है। अधिक सटीक रूप से, एक विशिष्ट क्षण में इसकी सही गणना की गई है, लेकिन औसत होने पर, यह एक मिनट के लिए कम होना चाहिए। उदाहरण के लिए, यदि एक वीएम (हाइपरविजर का एक तिहाई) 30 मिनट के लिए सभी सीपीयू का उपभोग करता है, तो एक मिनट के लिए एलए 0.15 होगा। चार ऐसे वीएम, एक ही समय में काम कर रहे हैं, जिसका परिणाम 0.6 होगा। एलए के आधार पर, आप यह नहीं निकाल पाएंगे कि उनमें से प्रत्येक के लिए 30 सेकंड के लिए, चोरी लगभग 25% थी।
  
• फिर से, शेड्यूलर की वजह से ऐसा हुआ, जिसने तय किया कि कोई बहुत ज्यादा "खा रहा था" और उन्हें इंतजार कर रहा था। इस बीच, यह संदर्भ, प्रक्रिया ब्रेकपॉइंट्स को स्विच करेगा, और अन्य महत्वपूर्ण सिस्टम मामलों में भाग लेगा। परिणामस्वरूप, कुछ VMs कोई समस्या नहीं अनुभव करते हैं, और अन्य महत्वपूर्ण प्रदर्शन हानि से पीड़ित हैं।
  

4. अन्य विकृतियाँ

एक वीएम पर उचित सीपीयू समय आवंटन के विरूपण के लिए दस लाख संभावित कारण हैं। उदाहरण के लिए, हाइपरथ्रेडिंग और एनयूएमए गणना में जटिलता जोड़ते हैं। वे एक प्रक्रिया को चलाने के लिए उपयोग किए जाने वाले कोर की पसंद को जटिल करते हैं क्योंकि एक अनुसूचक गुणांक का उपयोग करता है; यह वज़न कहना है, जो संदर्भों को बदलते समय गणना को इससे भी अधिक जटिल करता है।

टर्बो बूस्ट या इसके विपरीत, बिजली बचत मोड जैसी प्रौद्योगिकियों से उत्पन्न होने वाली विकृतियां हैं, जो सीपीयू कोर गति और यहां तक ​​कि समय स्लाइस को कृत्रिम रूप से बढ़ा या घटा सकती हैं। एक और एक प्रदर्शन में वृद्धि के कारण एक सीपीयू थ्रेड की उत्पादकता कम करने पर टर्बो बूस्ट को चालू करना। उस समय, वर्तमान सीपीयू घड़ी की गति के बारे में जानकारी वीएम को नहीं भेजी जाती है, जो सोचता है कि कोई अपना समय चुरा रहा है (जैसे उसने 2 गीगाहर्ट्ज का अनुरोध किया और आधे से अधिक हो गया)।

वास्तव में, विकृति के कई कारण हो सकते हैं। आप किसी भी सिस्टम में पूरी तरह से कुछ और पा सकते हैं। मैं उपर्युक्त पुस्तकों के साथ शुरू करने की सलाह देता हूं और परफ़ेक्टर, सीसडिग, सिस्टमटैप और दर्जनों अन्य जैसे टूल का उपयोग करके हाइपरवाइज़र से आंकड़े प्राप्त करता हूं।

5. निष्कर्ष

1. Paravirtualization के कारण कुछ चोरी दिखाई दे सकती है और इसे सामान्य माना जा सकता है। ऑनलाइन सूत्रों का कहना है कि यह मान 5-10% हो सकता है। यह एक वीएम के भीतर आवेदन पर निर्भर करता है, और वीएम अपने भौतिक उपकरणों पर लोड करता है। यह ध्यान देना महत्वपूर्ण है कि अनुप्रयोग एक वीएम के अंदर कैसा महसूस करते हैं।
   
2. हाइपरविजर पर लोड और एक वीएम के भीतर चोरी के बीच संबंध हमेशा निश्चित नहीं होता है। दोनों चोरी की गणना कुछ मामलों में और विभिन्न भारों के साथ गलत हो सकती है।
   
3. शेड्यूलर उन प्रक्रियाओं का पक्ष नहीं लेता है जो बहुत सारे संसाधनों का अनुरोध करते हैं। यह उन लोगों को कम देने की कोशिश करता है जो अधिक मांगते हैं। बड़े उदाहरण हैं।
   
4. थोड़ी सी चोरी पैरावर्टलाइज़ेशन के बिना भी सामान्य हो सकती है (वीएम के भीतर लोड को ध्यान में रखते हुए, पड़ोसियों के भार की विशिष्टताएं, थ्रेड्स और अन्य कारकों के बीच लोड का वितरण)।
   
5. यदि आप किसी विशेष प्रणाली में चोरी की गणना करना चाहते हैं, तो विभिन्न संभावनाओं पर शोध करें, मेट्रिक्स इकट्ठा करें, उनका पूरी तरह से विश्लेषण करें, और सोचें कि लोड को कैसे वितरित किया जाए। भले ही, विचलन हो सकते हैं, जिन्हें परीक्षण का उपयोग करके सत्यापित किया जाना चाहिए या इन्हें कर्नेल डिबगर में देखना चाहिए।