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

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

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

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

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

प्रदर्शन का विश्लेषण करने के लिए हमें आवश्यकता होगी:

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

सिद्धांत का एक छोटा सा

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

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

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

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

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

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

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

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

मेगाहर्ट्ज में सीपीयू उपयोग

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

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

कोर पर असमान भार का एक उदाहरण.

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

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

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

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

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

सीपीयू तैयार

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

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

vCenter में आप CPU रेडी से संबंधित 2 काउंटर देख सकते हैं:

• तत्परता,
• तैयार।

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

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

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

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

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

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

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

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

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

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

सह-विराम

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

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

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

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

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

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

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

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

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

रन - माप अवधि के दौरान वीसीपीयू कितने समय (एमएस) आरयूएन स्थिति में था, यानी यह वास्तव में उपयोगी कार्य कर रहा था।

निष्क्रिय - माप अवधि के दौरान कितने समय तक (एमएस) वीसीपीयू निष्क्रियता की स्थिति में था। उच्च निष्क्रिय मान कोई समस्या नहीं है, वीसीपीयू के पास बस "कुछ नहीं करना है।"

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

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

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

ईएसएक्सटीओपी

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

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

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

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

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

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

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

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

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

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

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

%इंतज़ार - माप अवधि के दौरान प्रक्रिया कितने समय तक प्रतीक्षा स्थिति में थी। आईडीएलई सक्षम करता है।

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

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

%VMप्रतीक्षा करें - माप अवधि के दौरान वीसीपीयू कितने समय तक किसी घटना की प्रतीक्षा की स्थिति में था (आमतौर पर I/O)। vCenter में कोई समान काउंटर नहीं है। उच्च मान वीएम पर I/O के साथ समस्याओं का संकेत देते हैं।

%WAIT = %VMWAIT + %IDLE + %SWPWT.

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

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

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

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

%WAIT + %RDY + %CSTP + %RUN = 100% - VM कोर हमेशा इन चार अवस्थाओं में से एक में होता है।

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

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

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

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

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

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

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

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

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

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

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

• कोर के लिए कोर यूटिलिटी 100% होगी,
• दोनों धागों के लिए पीसीपीयू यूटीआईएल 100% होगा,
• दोनों धागों के लिए पीसीपीयू का उपयोग 50% होगा।

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

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

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

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

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

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

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

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

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

उपयोगी लिंक्सhttp://virtual-red-dot.info/vm-cpu-counters-vsphere/
https://kb.vmware.com/kb/1017926
http://www.yellow-bricks.com/2012/07/17/why-is-wait-so-high/
https://communities.vmware.com/docs/DOC-9279
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/whats-new-vsphere65-perf.pdf
https://pages.rubrik.com/host-resources-deep-dive_request.html

स्रोत: www.habr.com