तीसरा भाग। पिछले भाग: पहला , दूसरा ।



इस विषय में: मेमोरी मैनेजमेंट और वर्चुअल मशीन प्रोसेसर।

स्मृति

यह समझने के लिए कि XCP मेमोरी के साथ कैसे काम करता है, आपको यह समझने की आवश्यकता है कि Xen इसके साथ कैसे काम करता है। OpenVZ के विपरीत, एक्सएमएल हमेशा एक वर्चुअल मशीन (अधिक सटीक, एक डोमेन) को विशेष उपयोग के लिए मेमोरी आवंटित करता है। डोमेन मेमोरी डोमेन मेमोरी है और इससे ज्यादा कुछ नहीं। कोई ओवरसेल नहीं, कोई साझा पृष्ठ नहीं, कोई हाइपरविजर स्वैप (वर्चुअल मशीनें स्वैप नहीं कर सकती हैं, निश्चित रूप से)। यदि आपके पास 4GB है, तो आप लगभग 3.5GB को गेस्ट मशीन के बीच विभाजित कर सकते हैं (512 डोम 0 पर जाएंगे)। आप उन्हें कैसे साझा करेंगे यह आपकी स्वतंत्रता है। लेकिन आप मशीन को उपलब्ध की तुलना में अधिक मेमोरी नहीं दे सकते। नहीं। बिंदु।



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



मेमोरी प्रबंधन मुफ्त नहीं है, यह व्यवसाय के खर्च के लिए डोमेन मेमोरी का एक सा हिस्सा लेता है। सबसे खराब स्थिति में, यह लगभग 5% है, अधिक मेमोरी, छोटा प्रतिशत (मेमोरी के 16GB तक, मान लगभग 1% तक गिरता है)।



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



इस मॉडल के आधार पर, एक सैद्धांतिक छत है (एक डोमेन बनाते समय निर्दिष्ट किया जाता है, यानी वर्चुअल मशीन शुरू करते समय), जिससे वर्चुअल मेमोरी का विस्तार किया जा सकता है। यह ओवरहेड की मात्रा को प्रभावित करता है, और कृत्रिम रूप से मेमोरी की निचली सीमा को सीमित करता है (16GB के लिए यह लगभग 512MB है, 2GB के लिए, ऐसा लगता है, 128MB)। इस प्रकार, हम दो सीमाएँ प्राप्त करते हैं जो डोमेन के शुरू होने पर सेट होती हैं - memory_static_min



और memory_static_max



। इस तथ्य के बावजूद कि उपयोगकर्ता मेमोरी_स्टैटिक_मिन को मनमाने ढंग से कम कर सकता है, मेमोरी की मात्रा अधिकतम से गणना की गई एक निश्चित मूल्य से नीचे कभी नहीं घटेगी। यह सीधे xenballloon.c कोड में इनकोड किया गया है और OOM हत्यारे को नीले रंग से बाहर निकलने से बचाने का काम करता है (ताकि कर्नेल सर्विस डेटा के लिए पर्याप्त मेमोरी और कामकाज के लिए सॉफ्टवेयर का एक न्यूनतम सेट)। कुछ स्थानों पर, यह बार को बहुत आक्रामक तरीके से उठाता है (विशेष रूप से 2-4 जीबी की छत क्षेत्र में), लेकिन सामान्य तौर पर, मूल्य काफी उचित हैं।



इन प्रतिबंधों के अलावा, दो और (कृत्रिम) मात्राएँ पेश की जाती हैं - memory_dynamic_max और memory_dynamic_min। ये मूल्य उन सीमाओं को परिभाषित करते हैं जिनके भीतर स्मृति समायोजित की जा सकती है और मक्खी पर बदल सकती है (यानी, यह बस एक प्रशासनिक सम्मेलन है)। मूल्य लक्ष्य (memory_target) - मेमोरी की वांछित मात्रा भी है। ज्यादातर, स्मृति की मात्रा आवश्यकतानुसार (यानी मेमोरी = मेमोरी_टार्गेट) की जाती है, लेकिन यदि लक्ष्य अनुरोध निष्पादित नहीं किया जा सकता है, तो ये मान भिन्न हो सकते हैं।



एक आभासी मशीन की मेमोरी क्षमता को विनियमित करने के लिए दो तरीके हैं - मैनुअल और स्वचालित। नियत मान के लिए मैनुअल लक्ष्य निर्धारित करता है। स्वचालित सीमाएँ (अधिकतम / न्यूनतम) निर्धारित करता है और प्रत्येक डोमेन की मेमोरी साइज़ को विनियमित करने की क्षमता के साथ XCP प्रदान करता है।



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



कमांड का उपयोग किए बिना इंगित किया जाता है कि कहां से शुरू करना है, तो मशीन वहां शुरू हो जाएगी जहां यह काम करता है, अगर यह "यहां शुरू करें" कहता है, तो विफलता होगी) लॉन्च पर)।



चलते-फिरते, आप उपलब्ध रेंज के भीतर, डायनामिक-मिन / अधिकतम मूल्यों को बदल सकते हैं। मूल्यों को बदलते समय, बदलने की संभावना की जांच नहीं की जाती है, और आप मेमोरी = 512Mb, डायनामिक-मिन = 2GiB, लक्ष्य = 4GiB, डायनेमिक-मैक्स = 8GiB के साथ एक मशीन प्राप्त कर सकते हैं। (रिबूट पर, यदि शर्तों को पूरा नहीं किया जा सकता है, तो मशीन शुरू नहीं होगी)।



किसी भी स्थिति में, स्मृति के लिए, प्रत्येक परिवर्तन के साथ, सूत्र की जाँच की जाती है:



static-min ≤ dynamic_min ≤ target ≤ dynamic_max ≤ static-max



प्रोसेसर (ओं)

X प्रोसेसर का डायनेमिक कनेक्शन / डिस्कनेक्शन सपोर्ट करता है। (और हाँ, टिप्पणियों से प्रश्नों का उत्तर देना - 4 से अधिक कोर हो सकते हैं, मैंने व्यक्तिगत रूप से एक वर्चुअल मशीन से 16 कोर देखे, प्रोसेसर की संख्या सीमित नहीं है)। डिफ़ॉल्ट रूप से, सभी मशीनों को एक प्रोसेसर के साथ बनाया जाता है; मल्टीप्रोसेसिंग को सक्षम करने के लिए, उन्हें बंद कर दिया जाना चाहिए। व्यवहार को निर्धारित करने वाले तीन मूल्य हैं:

• वीसीपीयूएस-मैक्स - एक डोमेन के लिए प्रोसेसर की अधिकतम संख्या (एक वर्चुअल मशीन चालू करते समय, यानी, एक डोमेन बनाते समय)।
• वीसीपीयूएस-संख्या - प्रोसेसर की वर्तमान संख्या
• वीसीपीयूएस-एट-स्टार्टअप - मशीन चालू होने पर प्रोसेसर की संख्या (एक डोमेन बनाना)

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



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



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



एक दूसरे के बीच, वर्चुअल मशीनों में प्रोसेसर की सीमाएं और सापेक्ष प्राथमिकताएं हो सकती हैं।



सीमा को कैप वैल्यू के रूप में सेट किया जाता है, जो प्रत्येक प्रोसेसर के लिए अधिकतम अनुमत मशीन समय का प्रतिशत निर्धारित करता है (प्रत्येक कोर के लिए, प्रत्येक कोर के लिए कैप = 75% मशीन समय का 150% है, कुछ प्रलेखन में वे कहते हैं कि कैप कुल खपत है। मशीनें, यानी कैप = 150, कैप = 330, आदि - यह सच नहीं है)। cap = 10 हमें 10% मशीन का समय देगा और एक शक्तिशाली Xeon को बहुत ही दुर्भाग्यपूर्ण P2 (या P1) में बदल देगा, यह बूट चरण में विशेष रूप से तीव्र है। सिद्धांत रूप में, टोपी को 25% से कम करना इसके लायक नहीं है, क्योंकि मशीन कंसोल में भी कुंद करना शुरू कर सकती है (आसानी से फैलाने वाली बैश प्रतियोगिता के साथ)।



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



रिश्ता सख्त है - वजन के साथ एक मशीन = 20 वजन के साथ एक मशीन की तुलना में कम से कम दो गुना अधिक मशीन समय प्राप्त करता है = 10 (यदि आप इस मशीन समय का उपभोग करना चाहते हैं, यदि "प्राथमिकता" मशीन निष्क्रिय है, तो कम-प्राथमिकता वाला उतना ही खा सकता है जितना वह चाहता है)। इन नंबरों को आसानी से दसियों हज़ार तक ले जाया जा सकता है (यानी, वज़न = 20,000 और वज़न = 1 के साथ एक मशीन हो सकती है, जिस स्थिति में दूसरा, वास्तव में, निष्क्रिय प्राथमिकता में काम करता है)।



महत्वपूर्ण: सभी प्राथमिकताएं, दुर्भाग्यवश, केवल तभी रोका जा सकता है जब डोमेन बंद हो जाए।



Giblets में खुदाई के विशेष रूप से पतले पारखी के लिए, वर्चुअल मशीन (तथाकथित VCPU-pinning) और प्रोसेसर की कुछ क्षमताओं (VPCU-features) को निष्क्रिय (अक्षम) करने की क्षमता के लिए विशिष्ट कोर निर्दिष्ट करना संभव है।



आप वर्चुअल मशीन के साथ वास्तविक स्थिति को xentop



का उपयोग करके देख सकते हैं।