चोरी: जो वर्चुअल मशीनों से प्रोसेसर का समय चुराता है

नमस्ते! मैं आपको वर्चुअल मशीनों के अंदर चोरी की प्रक्रिया और कुछ गैर-स्पष्ट कलाकृतियों के बारे में सरल शब्दों में बताना चाहता हूं, जिन्हें हम इसके शोध के दौरान पता लगाने में कामयाब रहे, जिसे मुझे क्लाउड प्लेटफ़ॉर्म के तकनीकी निदेशक के रूप में समझना पड़ा। Mail.ru क्लाउड सॉल्यूशंस. प्लेटफॉर्म KVM पर चलता है.

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

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

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

वर्चुअल मशीन कर्नेल हाइपरवाइज़र से चोरी मीट्रिक प्राप्त करता है। उसी समय, हाइपरवाइज़र यह निर्दिष्ट नहीं करता है कि वह कौन सी अन्य प्रक्रियाएँ चला रहा है, यह बस कहता है "जबकि मैं व्यस्त हूँ, मैं आपको समय नहीं दे सकता।" KVM पर, चोरी गणना के लिए समर्थन जोड़ा गया है पैच. यहां दो प्रमुख बिंदु हैं:

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

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

2.1. हिसाब चुराओ

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

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

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

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

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

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

अनुवाद. इस मामले में, भौतिक हाइपरवाइजर उपकरणों के साथ वर्चुअल मशीन ऑपरेटिंग सिस्टम का संचालन कुछ इस तरह होता है:

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

अनुवाद का लाभ यह है कि यह आपको किसी भी डिवाइस का अनुकरण करने की अनुमति देता है और इसके लिए ऑपरेटिंग सिस्टम कर्नेल की विशेष तैयारी की आवश्यकता नहीं होती है। लेकिन इसके लिए आपको सबसे पहले स्पीड के हिसाब से भुगतान करना होगा।

हार्डवेयर वर्चुअलाइजेशन. इस स्थिति में, हार्डवेयर स्तर पर डिवाइस ऑपरेटिंग सिस्टम के कमांड को समझता है। यह सबसे तेज़ और सबसे अच्छा तरीका है. लेकिन, दुर्भाग्य से, यह सभी भौतिक उपकरणों, हाइपरवाइज़र और अतिथि ऑपरेटिंग सिस्टम द्वारा समर्थित नहीं है। वर्तमान में, हार्डवेयर वर्चुअलाइजेशन का समर्थन करने वाले मुख्य उपकरण प्रोसेसर हैं।

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

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

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

2.3. "निष्पक्ष" शेड्यूलिंग

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

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

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

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

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

2.4. चोरी की निगरानी कैसे करें?

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

शीर्ष कमांड का आउटपुट: प्रोसेसर लोड का विवरण, सबसे दाहिने कॉलम में - चोरी

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

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

LA की एक और विशेषता यह है कि इसे एक ऑपरेटिंग सिस्टम औसत माना जाता है। उदाहरण के लिए, 100 प्रक्रियाएँ एक फ़ाइल के लिए प्रतिस्पर्धा कर रही हैं, और फिर LA=50। इतना बड़ा मान यह दर्शाता है कि ऑपरेटिंग सिस्टम खराब है। लेकिन अन्य टेढ़े-मेढ़े तरीके से लिखे गए कोड के लिए, यह एक सामान्य स्थिति हो सकती है, इस तथ्य के बावजूद कि केवल यह खराब है, और ऑपरेटिंग सिस्टम में अन्य प्रक्रियाएं प्रभावित नहीं होती हैं।

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

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

आइए अब हमारे सामने आए चोरी के मुख्य मामलों पर नजर डालें। मैं आपको बताऊंगा कि वे उपरोक्त सभी का कैसे पालन करते हैं और वे हाइपरवाइजर पर संकेतकों से कैसे संबंधित हैं।

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

पैरावर्चुअलाइजेशन बनाम एकल उदाहरण. हाइपरविजर पर केवल एक वर्चुअल मशीन है; यह इसका एक छोटा सा हिस्सा उपभोग करता है, लेकिन एक बड़ा I/O लोड उत्पन्न करता है, उदाहरण के लिए डिस्क पर। और कहीं न कहीं से इसमें एक छोटी सी चोरी दिखाई देती है, 10% तक (जैसा कि कई प्रयोगों से पता चला है)।

मामला दिलचस्प है. पैरावर्चुअलाइज्ड ड्राइवरों के स्तर पर अवरोधन के कारण चोरी यहाँ दिखाई देती है। वर्चुअल मशीन के अंदर एक रुकावट पैदा की जाती है, जिसे ड्राइवर द्वारा संसाधित किया जाता है और हाइपरवाइजर को भेजा जाता है। हाइपरविजर पर इंटरप्ट हैंडलिंग के कारण, वर्चुअल मशीन के लिए यह एक भेजे गए अनुरोध की तरह दिखता है, यह निष्पादन के लिए तैयार है और प्रोसेसर की प्रतीक्षा कर रहा है, लेकिन इसे प्रोसेसर का समय नहीं दिया गया है। आभासी लड़की सोचती है कि यह समय चोरी हो गया है।

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

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

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

कम एलए, लेकिन चोरी है. यदि एलए लगभग 0,7 है (अर्थात, हाइपरविजर अंडरलोड प्रतीत होता है), लेकिन व्यक्तिगत वर्चुअल मशीनों के अंदर चोरी देखी जाती है:

• पैरावर्चुअलाइजेशन वाला विकल्प पहले ही ऊपर वर्णित है। वर्चुअल मशीन चोरी का संकेत देने वाले मेट्रिक्स प्राप्त कर सकती है, हालांकि हाइपरवाइजर ठीक है। हमारे प्रयोगों के परिणामों के अनुसार, यह चोरी विकल्प 10% से अधिक नहीं है और वर्चुअल मशीन के अंदर अनुप्रयोगों के प्रदर्शन पर इसका महत्वपूर्ण प्रभाव नहीं होना चाहिए।
• एलए पैरामीटर की गणना गलत तरीके से की गई है। अधिक सटीक रूप से, प्रत्येक विशिष्ट क्षण में इसकी गणना सही ढंग से की जाती है, लेकिन जब एक मिनट से अधिक का औसत निकाला जाता है तो यह कम आंका जाता है। उदाहरण के लिए, यदि हाइपरवाइजर की प्रति तिहाई एक वर्चुअल मशीन ठीक आधे मिनट के लिए अपने सभी प्रोसेसर का उपभोग करती है, तो हाइपरवाइजर पर एलए प्रति मिनट 0,15 होगा; एक साथ काम करने वाली ऐसी चार वर्चुअल मशीनें 0,6 देंगी। और तथ्य यह है कि उनमें से प्रत्येक पर आधे मिनट के लिए एलए संकेतक के अनुसार 25% की बेतहाशा चोरी हुई थी, अब इसे बाहर नहीं निकाला जा सकता है।
• फिर, शेड्यूलर के कारण जिसने निर्णय लिया कि कोई बहुत अधिक खा रहा है और किसी को इंतजार करने दें। इस बीच, मैं संदर्भ बदल दूँगा, व्यवधानों को संभाल लूँगा और अन्य महत्वपूर्ण सिस्टम चीज़ों का ध्यान रखूँगा। परिणामस्वरूप, कुछ वर्चुअल मशीनों में कोई समस्या नहीं दिखती है, जबकि अन्य को गंभीर प्रदर्शन में गिरावट का अनुभव होता है।

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

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

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

सामान्यतः विकृति के अनेक कारण हो सकते हैं। आपको किसी विशेष सिस्टम पर कुछ और भी मिल सकता है। उन पुस्तकों से शुरुआत करना बेहतर है जिनके लिए मैंने ऊपर लिंक दिए हैं, और हाइपरवाइज़र से पर्फ, सिसडिग, सिस्टमटैप जैसी उपयोगिताओं का उपयोग करके आंकड़े पुनर्प्राप्त करना बेहतर है, जिनमें से के दर्जनों.

5। निष्कर्ष

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

स्रोत: www.habr.com