VMware vSphere में वर्चुअल मशीन के प्रदर्शन का विश्लेषण। भाग 1: सीपीयू

यदि आप VMware vSphere (या किसी अन्य प्रौद्योगिकी स्टैक) के आधार पर एक आभासी बुनियादी ढांचे का प्रबंधन करते हैं, तो आप अक्सर उपयोगकर्ताओं से शिकायतें सुनते हैं: "वर्चुअल मशीन धीमी है!"। लेखों की इस श्रृंखला में मैं प्रदर्शन मेट्रिक्स का विश्लेषण करूंगा और समझाऊंगा कि यह "धीमा" क्यों और कैसे सुनिश्चित करें कि यह "धीमा" नहीं है।

मैं आभासी मशीनों के निम्नलिखित प्रदर्शन पहलुओं पर विचार करूंगा:

• सीपीयू,
• रैम,
• डिस्क,
• नेटवर्क।

मैं सीपीयू के साथ शुरू करूँगा।

प्रदर्शन विश्लेषण के लिए हमें चाहिए:

• vCenter परफॉरमेंस काउंटर्स परफॉरमेंस काउंटर्स होते हैं जिनका ग्राफ vSphere Client के माध्यम से देखा जा सकता है। इन काउंटरों पर जानकारी किसी भी क्लाइंट संस्करण (सी # में "मोटी" क्लाइंट, फ्लेक्स पर वेब क्लाइंट और एचटीएमएल 5 पर वेब क्लाइंट) में उपलब्ध है। इन लेखों में, हम C # क्लाइंट के स्क्रीनशॉट का उपयोग करेंगे, केवल इसलिए कि वे लघु में बेहतर दिखते हैं :)
• ESXTOP एक उपयोगिता है जो ESXi कमांड लाइन से चलती है। इसकी सहायता से, आप वास्तविक समय में प्रदर्शन काउंटर के मान प्राप्त कर सकते हैं या आगे के विश्लेषण के लिए एक निश्चित अवधि के लिए इन मूल्यों को एक .csv फ़ाइल में अपलोड कर सकते हैं। इसके बाद, मैं आपको इस टूल के बारे में अधिक बताऊंगा और प्रलेखन और संबंधित लेखों के लिए कुछ उपयोगी लिंक प्रदान करूंगा।

सिद्धांत की बिट

ESXi में, प्रत्येक vCPU (वर्चुअल मशीन कोर) के संचालन के लिए एक अलग प्रक्रिया जिम्मेदार है - VMware शब्दावली में दुनिया। सेवा प्रक्रियाएं भी हैं, लेकिन वीएम प्रदर्शन विश्लेषण के दृष्टिकोण से, वे कम दिलचस्प नहीं हैं।

ESXi में एक प्रक्रिया चार राज्यों में से एक में हो सकती है:

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

वर्चुअल मशीन के बेसिक सीपीयू प्रदर्शन काउंटर

CPU उपयोग,% एक निश्चित अवधि के लिए CPU उपयोग का प्रतिशत दिखाता है।



विश्लेषण कैसे करें? अगर VM stably 90% तक CPU का उपयोग करता है या 100% तक की चोटियाँ हैं, तो हमें समस्याएँ हैं। VM के अंदर एप्लिकेशन के "धीमे" संचालन में न केवल समस्याएं व्यक्त की जा सकती हैं, बल्कि नेटवर्क पर VM की दुर्गमता भी हो सकती है। यदि मॉनिटरिंग सिस्टम दिखाता है कि वीएम समय-समय पर गिरता है, तो सीपीयू उपयोग ग्राफ में चोटियों पर ध्यान दें।

एक मानक अलार्म है, जो वर्चुअल मशीन के सीपीयू लोड को दिखाता है:



क्या करें? यदि सीपीयू उपयोग लगातार वीएम को भारी कर रहा है, तो आप वीसीपीयू की संख्या बढ़ाने के बारे में सोच सकते हैं (दुर्भाग्य से, यह हमेशा मदद नहीं करता है) या वीएम को अधिक कुशल प्रोसेसर वाले सर्वर में स्थानांतरित करना।

Mhz में CPU उपयोग

% में vCenter उपयोग ग्राफ़ में आप केवल संपूर्ण वर्चुअल मशीन देख सकते हैं, व्यक्तिगत कोर के लिए कोई ग्राफ़ नहीं हैं (Esxtop में कोर के लिए% में मान हैं)। प्रत्येक कोर के लिए, आप उपयोग मेगाहर्ट्ज में देख सकते हैं।

विश्लेषण कैसे करें? ऐसा होता है कि एप्लिकेशन मल्टी-कोर आर्किटेक्चर के लिए अनुकूलित नहीं है: यह 100% केवल एक कोर का उपयोग करता है, और बाकी बिना लोड के बेकार हैं। उदाहरण के लिए, डिफ़ॉल्ट बैकअप सेटिंग्स के साथ, एमएस SQL ​​केवल एक कोर पर प्रक्रिया शुरू करता है। नतीजतन, बैकअप धीमी गति की वजह से धीमा हो जाता है (यह वही है जो उपयोगकर्ता ने शुरू में शिकायत की थी), लेकिन क्योंकि प्रोसेसर सामना नहीं कर सकता है। मापदंडों को बदलकर समस्या को हल किया गया था: बैकअप कई फाइलों (क्रमशः, कई प्रक्रियाओं में) के समानांतर चलने लगा।


नाभिक के असमान भार का एक उदाहरण।

एक स्थिति भी है (जैसा कि ऊपर के ग्राफ में है) जब कोर असमान रूप से भरी हुई हैं और उनमें से कुछ में 100% की चोटियां हैं। केवल एक कोर लोड करने के साथ, सीपीयू उपयोग पर अलार्म काम नहीं करेगा (यह पूरे वीएम पर है), लेकिन प्रदर्शन की समस्याएं होंगी।

क्या करें? यदि वर्चुअल मशीन में सॉफ़्टवेयर कर्नेल को असमान रूप से लोड करता है (केवल एक कोर या गुठली का हिस्सा उपयोग करता है), तो उनकी संख्या बढ़ाने का कोई मतलब नहीं है। इस मामले में, वीएम को अधिक कुशल प्रोसेसर वाले सर्वर में स्थानांतरित करना बेहतर है।

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

VMware सर्वरों पर ऊर्जा-बचत तकनीकों को बंद नहीं करने की सलाह देता है, लेकिन उन तरीकों को चुनने के लिए जो हाइपरवाइज़र के लिए ऊर्जा प्रबंधन को अधिकतम करते हैं। उसी समय, हाइपरविजर की पावर सेटिंग्स में आपको उच्च प्रदर्शन का चयन करने की आवश्यकता होती है।

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

CPU तैयार (तत्परता)

यदि VM कोर (vCPU) रेडी अवस्था में है, तो यह उपयोगी कार्य नहीं करता है। यह स्थिति तब होती है जब हाइपरविजर को एक मुफ्त भौतिक कोर नहीं मिलता है जिससे वर्चुअल मशीन की वीसीपीयू प्रक्रिया को सौंपा जा सकता है।

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

VCenter में, आप CPU रेडी से जुड़े 2 काउंटर देख सकते हैं:

• तैयारी,
• तैयार है।

दोनों काउंटरों के मूल्यों को पूरे वीएम पर और व्यक्तिगत गुठली के लिए दोनों पर देखा जा सकता है।
तत्परता प्रतिशत में तुरंत मूल्य दर्शाती है, लेकिन केवल वास्तविक समय में (अंतिम घंटे के लिए डेटा, माप अंतराल 20 सेकंड)। इस काउंटर का उपयोग केवल समस्याओं के लिए खोज करने के लिए किया जाता है "गर्म खोज में।"

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

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

(सीपीयू तैयार योग मूल्य / (सेकंड में चार्ट डिफ़ॉल्ट अद्यतन अंतराल * 1000)) * 100 = सीपीयू तैयार%

उदाहरण के लिए, नीचे दिए गए ग्राफ़ में VMs के लिए, पूरे वर्चुअल मशीन के लिए रेडी का शिखर मान इस प्रकार है:

$$$(4286 / (20 * 1000)) * 100 = 21% (4286 / (20 * 1000)) * 100 = 21%$



प्रतिशत के रूप में तैयार मूल्य की गणना करते समय, आपको दो बिंदुओं पर ध्यान देना चाहिए:

• पूरे वीएम में रेडी का मूल्य कोर के पार रेडी का योग है।
• मापन अंतराल। वास्तविक समय के लिए, यह 20 सेकंड है, और, उदाहरण के लिए, दैनिक चार्ट पर, यह 300 सेकंड है।

सक्रिय समस्या निवारण के साथ, इन सरल बिंदुओं को आसानी से याद किया जा सकता है और गैर-मौजूद समस्याओं को हल करने में मूल्यवान समय व्यतीत किया जा सकता है।

हम नीचे दिए गए ग्राफ से डेटा के आधार पर रेडी की गणना करते हैं। (324474 / (20 * 1000)) * 100 = 1622% पूरे वीएम के लिए। यदि आप कोर को देखते हैं, तो यह इतना डरावना नहीं निकलेगा: 1622/64 = 25% प्रति कोर। इस मामले में, एक चाल का पता लगाना काफी सरल है: तैयार मूल्य अवास्तविक है। लेकिन अगर हम पूरे वीएम के लिए कई कोर के साथ 10-20% के बारे में बात कर रहे हैं, तो प्रत्येक कोर के लिए मूल्य सामान्य सीमा के भीतर हो सकता है।



क्या करें? रेडी का एक उच्च मूल्य इंगित करता है कि वर्चुअल मशीन के सामान्य संचालन के लिए सर्वर में पर्याप्त प्रोसेसर संसाधन नहीं हैं। इस स्थिति में, यह प्रोसेसर (vCPU: pCPU) पर ओवरस्क्रिप्शन को कम करने के लिए ही रहता है। जाहिर है, यह मौजूदा वीएम के मापदंडों को कम करके या वीएम के भाग को अन्य सर्वरों में स्थानांतरित करके प्राप्त किया जा सकता है।

सह-स्टॉप

विश्लेषण कैसे करें? इस काउंटर का योग भी है और रेडी की तरह प्रतिशत में अनुवाद करता है:

(CPU को-स्टॉप समन मान / (सेकंड में चार्ट डिफॉल्ट अपडेट अंतराल * 1000)) * 100 = CPU को-स्टॉप%

यहां आपको प्रति वीएम कोर की संख्या और माप अंतराल पर भी ध्यान देने की आवश्यकता है।
कॉस्टोप स्टेट में, कर्नेल उपयोगी कार्य नहीं करता है। वीएम आकार के सही चयन और सर्वर पर सामान्य भार के साथ, को-स्टॉप काउंटर शून्य के करीब होना चाहिए।


इस मामले में, लोड स्पष्ट रूप से असामान्य है :)

क्या करें? यदि बड़ी संख्या में कोर के साथ कई वीएम एक ही हाइपरवाइजर पर चल रहे हैं और सीपीयू पर ओवरस्क्रिप्शन है, तो सह-स्टॉप काउंटर बढ़ सकता है, जिससे इन वीएम के प्रदर्शन के साथ समस्याएं हो सकती हैं।

इसके अलावा, सह-स्टॉप बढ़ेगा यदि थ्रेड्स का उपयोग उसी वीएम के सक्रिय कर्नेल के लिए एक ही भौतिक सर्वर कोर पर हाइपर-ट्रेंडिंग के साथ किया जाता है। ऐसी स्थिति उत्पन्न हो सकती है, उदाहरण के लिए, यदि VM के पास भौतिक रूप से सर्वर पर जहां यह काम करता है, उससे अधिक कोर है, या यदि "पसंदीदा" सेटिंग VM के लिए सक्षम है। आप इस सेटिंग के बारे में यहां पढ़ सकते हैं।

उच्च सह-स्टॉप के कारण वीएम प्रदर्शन के साथ समस्याओं से बचने के लिए, इस वीएम पर चलने वाले सॉफ़्टवेयर निर्माता की सिफारिशों के अनुसार और वीएम चल रहे भौतिक सर्वर की क्षमताओं के अनुसार वीएम आकार का चयन करें।

रिजर्व में गुठली न जोड़ें, इससे न केवल वीएम की बल्कि उसके सर्वर पड़ोसियों की भी प्रदर्शन समस्याएं हो सकती हैं।

अन्य उपयोगी CPU मेट्रिक्स

भागो - vCPU माप अवधि के लिए कितना समय (ms) RUN राज्य में था, अर्थात, वास्तव में उपयोगी कार्य किया गया था।

निष्क्रिय - vCPU माप अवधि के लिए कितना समय (ms) निष्क्रिय था। हाई आइडल वैल्यू कोई समस्या नहीं है, बस vCPU के पास "कुछ नहीं करना है।"

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

अधिकतम सीमित - निर्धारित संसाधन सीमा के कारण vCPU मापन अवधि के लिए कितना समय (ms) तैयार अवस्था में था। यदि प्रदर्शन बेवजह कम है, तो इस काउंटर के मूल्य और वीएम सेटिंग्स में सीपीयू सीमा की जांच करना उपयोगी है। VMs की वास्तव में सीमाएँ हो सकती हैं जिनके बारे में आपको जानकारी नहीं है। उदाहरण के लिए, यह तब होता है जब वीएम को उस टेम्पलेट से ढलान दिया गया था जिस पर सीपीयू सीमा निर्धारित की गई थी।

स्वैप प्रतीक्षा - माप अवधि के दौरान VMCP कर्नल स्वैप के साथ vCPU के संचालन के लिए कितनी देर तक प्रतीक्षा की गई। यदि इस काउंटर का मान शून्य से ऊपर है, तो वीएम को निश्चित रूप से प्रदर्शन समस्याएं हैं। हम रैम काउंटर के बारे में लेख में SWAP के बारे में अधिक बात करेंगे।

ESXTOP

यदि vCenter में प्रदर्शन काउंटर ऐतिहासिक डेटा के विश्लेषण के लिए अच्छे हैं, तो समस्या का ऑन-लाइन विश्लेषण ESXTOP में सबसे अच्छा किया जाता है। यहां, सभी मानों को तैयार रूप में प्रस्तुत किया गया है (कुछ भी अनुवाद करने की आवश्यकता नहीं है), और न्यूनतम माप अवधि 2 सेकंड है।
CPU पर ESXTOP स्क्रीन को "c" कुंजी द्वारा बुलाया जाता है और इस तरह दिखता है:



सुविधा के लिए, आप Shift-V दबाकर केवल वर्चुअल मशीन प्रक्रियाओं को छोड़ सकते हैं।
व्यक्तिगत VM कोर के लिए मीट्रिक देखने के लिए, "e" दबाएं और VM के GID में टाइप करें जिसे आप (30919 नीचे स्क्रीनशॉट में) रुचि रखते हैं:



संक्षेप में डिफ़ॉल्ट रूप से प्रस्तुत किए गए कॉलम से गुजरें। अतिरिक्त कॉलम "एफ" दबाकर जोड़ा जा सकता है।

NWLD (संसारों की संख्या ) - समूह में प्रक्रियाओं की संख्या। समूह का विस्तार करने के लिए और प्रत्येक प्रक्रिया के लिए मैट्रिक्स देखें (उदाहरण के लिए, मल्टी-कोर वीएम के प्रत्येक कोर के लिए), "ई" दबाएं। यदि किसी समूह में एक से अधिक प्रक्रियाएँ हैं, तो समूह के लिए मीट्रिक के मान व्यक्तिगत प्रक्रियाओं के लिए मीट्रिक के योग के बराबर हैं।

% USED - सर्वर के सीपीयू कितने चक्र या प्रक्रियाओं के समूह का उपयोग करता है।

% RUN - माप अवधि के दौरान कितना समय RUN राज्य में था, अर्थात उपयोगी कार्य किया। यह% USED से भिन्न है कि यह हाइपर-थ्रेडिंग, आवृत्ति स्केलिंग और सिस्टम कार्यों पर खर्च किए गए समय (% SYS) को ध्यान में नहीं रखता है।

% SYS - सिस्टम कार्यों पर खर्च होने वाला समय, उदाहरण के लिए: इंटरप्ट, इनपुट / आउटपुट, नेटवर्क ऑपरेशन आदि को हैंडल करना। VM पर बहुत अधिक इनपुट / आउटपुट होने पर मान अधिक हो सकता है।

% OVRLP - भौतिक कोर जिस पर VM प्रक्रिया अन्य प्रक्रियाओं के कार्यों पर खर्च की जा रही है, कितना समय।

ये मीट्रिक इस प्रकार से संबंधित हैं:

% USED =% RUN +% SYS -% OVRLP।

आमतौर पर% USED मीट्रिक अधिक जानकारीपूर्ण होती है।

% WAIT - माप की अवधि के दौरान कितना समय प्रक्रिया प्रतीक्षा स्थिति में थी। IDLE शामिल है।

% IDLE - माप अवधि के दौरान IDLE स्थिति में प्रक्रिया कितनी लंबी थी।

% SWPWT - वीसीपीयू ने माप अवधि के दौरान वीकेकर्नल स्वैप के साथ ऑपरेशन के लिए कितने समय तक इंतजार किया।

% VMWAIT - माप अवधि के दौरान किसी घटना (आमतौर पर I / O) की प्रतीक्षा स्थिति में vCPU कब तक था। VCenter में समान काउंटर नहीं है। उच्च मान VM को इनपुट / आउटपुट के साथ समस्याओं का संकेत देते हैं।

% WAIT =% VMWAIT +% IDLE +% SWPWT।

यदि VM VMkernel Swap का उपयोग नहीं करता है, तो प्रदर्शन समस्याओं का विश्लेषण करते समय% VMWAIT को देखने की सलाह दी जाती है, क्योंकि यह मीट्रिक उस समय को ध्यान में नहीं रखती है जब VM ने कुछ भी नहीं किया था (% IDLE)।

% RDY - माप की अवधि के दौरान तैयार अवस्था में प्रक्रिया कितनी लंबी थी।

% CSTP - माप की अवधि के दौरान पोस्ट राज्य में प्रक्रिया कितनी लंबी थी।

% MLMTD - सेट संसाधन सीमा के कारण vCPU माप अवधि के दौरान तैयार अवस्था में कितना समय था।

% WAIT +% RDY +% CSTP +% RUN = 100% - VM कोर हमेशा इन चार राज्यों में से एक है।

हाइपरवाइजर पर सी.पी.यू.

VCenter में हाइपरविजर के लिए CPU प्रदर्शन काउंटर भी हैं, लेकिन वे कुछ भी दिलचस्प का प्रतिनिधित्व नहीं करते हैं - यह सर्वर पर सभी वीएम के लिए काउंटरों का योग है।
सारांश टैब पर सर्वर पर सीपीयू की स्थिति देखने का सबसे सुविधाजनक तरीका है:



सर्वर के लिए, साथ ही साथ वर्चुअल मशीन के लिए, एक मानक अलार्म है:



सर्वर के सीपीयू पर अधिक लोड होने से, उस पर चलने वाले VMs प्रदर्शन समस्याओं का अनुभव करने लगते हैं।

ESXTOP में, सर्वर CPU उपयोग डेटा को स्क्रीन के शीर्ष पर प्रस्तुत किया जाता है। मानक सीपीयू लोड के अलावा, जो हाइपरविजर्स के लिए असंक्रामक है, तीन और मैट्रिक्स हैं:

कोर UTIL (%) - भौतिक सर्वर की कोर लोड हो रहा है। यह काउंटर दिखाता है कि माप अवधि के दौरान कर्नेल ने कितने समय में काम किया।

PCPU UTIL (%) - यदि हाइपर-थ्रेडिंग सक्षम है, तो प्रत्येक भौतिक कोर के लिए दो थ्रेड्स (PCPU) हैं। यह मीट्रिक दिखाता है कि प्रत्येक थ्रेड ने कितना समय काम किया।

PCPU USED (%) PCPU UTIL (%) के समान है, लेकिन यह आवृति स्केलिंग (या तो ऊर्जा बचत के लिए कोर फ़्रीक्वेंसी को कम करने या टर्बो बूस्ट तकनीक के कारण कोर फ़्रीक्वेंसी को बढ़ाने) और हाइपर-थ्रेडिंग को ध्यान में रखता है।

PCPU_USED% = PCPU_UTIL% * प्रभावी कोर आवृत्ति / नाममात्र कोर आवृत्ति।


इस स्क्रीनशॉट में, कुछ कोर के लिए, टर्बो बूस्ट के संचालन के कारण, यूएसईडी मूल्य 100% से अधिक है, क्योंकि कोर आवृत्ति नाममात्र से अधिक है।

हाइपर-थ्रेडिंग को कैसे ध्यान में रखा जाता है, इसके बारे में कुछ शब्द। यदि प्रक्रियाएं सर्वर के भौतिक कोर के दोनों थ्रेड्स पर 100% समय चलती हैं, जबकि कोर नाममात्र कोर पर चलता है, तो:

• कोरल के लिए कोर UTIL 100% होगा,
• दोनों धागे के लिए PCPU UTIL 100% होगा,
• दोनों थ्रेड्स के लिए PCED का उपयोग 50% होगा।

यदि माप के दौरान दोनों थ्रेड्स 100% समय पर काम नहीं करते हैं, तो उन अवधि में जब थ्रेड्स समानांतर में काम करते हैं, कोर के लिए USED PCPU आधे में विभाजित है।

ESXTOP में CPU सर्वर के बिजली की खपत के मापदंडों के साथ एक स्क्रीन भी है। यहां आप देख सकते हैं कि क्या सर्वर ऊर्जा-बचत तकनीकों का उपयोग करता है: सी-स्टेट्स और पी-स्टेट्स। पी कुंजी द्वारा कॉल किया गया:

सामान्य CPU प्रदर्शन समस्याएँ

अंत में, मैं CPU VM के प्रदर्शन के साथ समस्याओं के विशिष्ट कारणों के लिए जाऊंगा और उन्हें हल करने के लिए संक्षिप्त सुझाव दूंगा:

पर्याप्त कोर क्लॉक स्पीड नहीं। यदि वीएम को अधिक कुशल कर्नेल में स्थानांतरित करने का कोई तरीका नहीं है, तो आप टर्बो बूस्ट को अधिक कुशलता से काम करने के लिए ऊर्जा सेटिंग्स को बदलने की कोशिश कर सकते हैं।

VM का गलत आकार (बहुत अधिक / कुछ कोर)। यदि आप कुछ कोर डालते हैं, तो वीएम सीपीयू पर एक उच्च भार होगा। यदि बहुत कुछ है, तो एक उच्च सह-स्टॉप को पकड़ें।

सर्वर पर सीपीयू पर बड़े ओवरस्क्रिप्शन। यदि वीएम उच्च तैयार है, तो सीपीयू पर ओवरस्क्रिप्शन को कम करें।

बड़े वीएम पर गलत NUMA टोपोलॉजी। NUMA टोपोलॉजी जिसे VM देखता है (vNUMA) NUMA सर्वर टोपोलॉजी (pNUMA) से मेल खाना चाहिए। निदान और इस समस्या के संभावित समाधान के बारे में, उदाहरण के लिए, "VMware vSphere 6.5 होस्ट रिसोर्स डीप हाइव" पुस्तक में लिखा गया है। यदि आप गहराई में नहीं जाना चाहते हैं और आपके पास VM पर स्थापित OS पर लाइसेंस प्रतिबंध नहीं है, तो VM पर एक कोर पर बहुत सारे वर्चुअल सॉकेट करें। आपने बहुत कुछ नहीं जीता :)

यह सब सीपीयू के लिए है। प्रश्न पूछें। अगले भाग में मैं रैम के बारे में बात करूंगा।