VMware vSphere मधील आभासी मशीन कार्यक्षमतेचे विश्लेषण. भाग 1: CPU

जर तुम्ही VMware vSphere (किंवा इतर कोणत्याही तंत्रज्ञान स्टॅक) वर आधारित व्हर्च्युअल इन्फ्रास्ट्रक्चर प्रशासित करत असाल, तर तुम्हाला बहुधा वापरकर्त्यांकडून तक्रारी ऐकायला मिळतात: “व्हर्च्युअल मशीन मंद आहे!” लेखांच्या या मालिकेत मी कार्यप्रदर्शन मेट्रिक्सचे विश्लेषण करेन आणि ते काय आणि का कमी होते आणि ते कमी होत नाही याची खात्री कशी करावी हे सांगेन.

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

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

मी CPU ने सुरुवात करेन.

कामगिरीचे विश्लेषण करण्यासाठी आम्हाला याची आवश्यकता असेल:

• vCenter कामगिरी काउंटर - कार्यप्रदर्शन काउंटर, ज्याचे आलेख vSphere क्लायंटद्वारे पाहिले जाऊ शकतात. या काउंटरवरील माहिती क्लायंटच्या कोणत्याही आवृत्तीमध्ये उपलब्ध आहे (C# मधील “जाड” क्लायंट, फ्लेक्समधील वेब क्लायंट आणि HTML5 मधील वेब क्लायंट). या लेखांमध्ये आम्ही C# क्लायंटचे स्क्रीनशॉट्स वापरू, कारण ते सूक्ष्मात चांगले दिसतात :)
• ESXTOP - एक उपयुक्तता जी ESXi कमांड लाइनवरून चालते. त्याच्या मदतीने, तुम्ही रिअल टाइममध्ये परफॉर्मन्स काउंटरची मूल्ये मिळवू शकता किंवा पुढील विश्लेषणासाठी विशिष्ट कालावधीसाठी ही मूल्ये .csv फाइलमध्ये अपलोड करू शकता. पुढे, मी तुम्हाला या साधनाबद्दल अधिक सांगेन आणि या विषयावरील दस्तऐवजीकरण आणि लेखांसाठी अनेक उपयुक्त दुवे प्रदान करेन.

सिद्धांताचा बिट

ESXi मध्ये, एक वेगळी प्रक्रिया - VMware शब्दावलीतील जग - प्रत्येक vCPU (व्हर्च्युअल मशीन कोर) च्या ऑपरेशनसाठी जबाबदार आहे. सेवा प्रक्रिया देखील आहेत, परंतु व्हीएम कार्यप्रदर्शनाचे विश्लेषण करण्याच्या दृष्टिकोनातून ते कमी मनोरंजक आहेत.

ESXi मधील प्रक्रिया चारपैकी एका स्थितीत असू शकते:

• चालवा - प्रक्रिया काही उपयुक्त कार्य करते.
• प्रतीक्षा - प्रक्रिया कोणतेही काम करत नाही (निष्क्रिय) किंवा इनपुट/आउटपुटची वाट पाहत आहे.
• कॉस्टॉप - मल्टी-कोर व्हर्च्युअल मशीनमध्ये उद्भवणारी स्थिती. जेव्हा हायपरवाइजर CPU शेड्युलर (ESXi CPU शेड्युलर) फिजिकल सर्व्हर कोरवर सर्व सक्रिय व्हर्च्युअल मशीन कोरच्या एकाचवेळी अंमलबजावणीचे वेळापत्रक करू शकत नाही तेव्हा असे होते. भौतिक जगात, सर्व प्रोसेसर कोर समांतरपणे कार्य करतात, VM मधील अतिथी OS समान वर्तनाची अपेक्षा करते, म्हणून हायपरवाइझरला VM कोर कमी करावे लागतात ज्यात त्यांचे घड्याळ चक्र जलद पूर्ण करण्याची क्षमता असते. ESXi च्या आधुनिक आवृत्त्यांमध्ये, CPU शेड्युलर आरामशीर सह-शेड्युलिंग नावाची यंत्रणा वापरतो: हायपरवाइजर "सर्वात वेगवान" आणि "सर्वात हळू" व्हर्च्युअल मशीन कोर (स्क्यू) मधील अंतर विचारात घेतो. जर अंतर एका विशिष्ट थ्रेशोल्डपेक्षा जास्त असेल तर, वेगवान कोर कॉस्टॉप स्थितीत प्रवेश करतो. VM कोर या स्थितीत बराच वेळ घालवत असल्यास, यामुळे कार्यप्रदर्शन समस्या उद्भवू शकतात.
• तयार - जेव्हा हायपरवाइजर त्याच्या अंमलबजावणीसाठी संसाधने वाटप करण्यास अक्षम असतो तेव्हा प्रक्रिया या स्थितीत प्रवेश करते. उच्च तयार मूल्यांमुळे VM कार्यप्रदर्शन समस्या उद्भवू शकतात.

मूलभूत आभासी मशीन CPU कामगिरी काउंटर

CPU वापर, %. दिलेल्या कालावधीसाठी CPU वापराची टक्केवारी दाखवते.

विश्लेषण कसे करावे? जर VM सातत्याने 90% वर CPU वापरत असेल किंवा 100% पर्यंत शिखरे असतील, तर आम्हाला समस्या आहेत. समस्या केवळ व्हीएममधील अनुप्रयोगाच्या "धीमे" ऑपरेशनमध्येच नव्हे तर नेटवर्कवरील व्हीएमच्या दुर्गमतेमध्ये देखील व्यक्त केल्या जाऊ शकतात. जर मॉनिटरिंग सिस्टम दाखवत असेल की VM वेळोवेळी बंद पडतो, तर CPU वापर ग्राफमधील शिखरांकडे लक्ष द्या.

एक मानक अलार्म आहे जो आभासी मशीनचा CPU लोड दर्शवतो:

मी काय करावे? जर VM चा CPU वापर सतत छतावरुन जात असेल, तर तुम्ही vCPU ची संख्या वाढविण्याचा विचार करू शकता (दुर्दैवाने, हे नेहमीच मदत करत नाही) किंवा VM ला अधिक शक्तिशाली प्रोसेसर असलेल्या सर्व्हरवर हलवण्याचा विचार करू शकता.

MHz मध्ये CPU वापर

% मधील vCenter वापरावरील आलेखांमध्ये तुम्ही केवळ संपूर्ण व्हर्च्युअल मशीनसाठी पाहू शकता (Extop मध्ये कोरसाठी % मूल्ये आहेत). प्रत्येक कोरसाठी तुम्ही MHz मध्ये वापर पाहू शकता.

विश्लेषण कसे करावे? असे घडते की मल्टी-कोर आर्किटेक्चरसाठी ॲप्लिकेशन ऑप्टिमाइझ केलेले नाही: ते फक्त एक कोर 100% वापरते आणि उर्वरित लोडशिवाय निष्क्रिय असतात. उदाहरणार्थ, डीफॉल्ट बॅकअप सेटिंग्जसह, MS SQL केवळ एका कोरवर प्रक्रिया सुरू करते. परिणामी, डिस्कच्या मंद गतीमुळे बॅकअप कमी होत नाही (वापरकर्त्याने सुरुवातीला याची तक्रार केली होती), परंतु प्रोसेसर सामना करू शकत नाही म्हणून. पॅरामीटर्स बदलून समस्या सोडवली गेली: बॅकअप अनेक फायलींमध्ये (अनुक्रमे, अनेक प्रक्रियांमध्ये) समांतर चालण्यास सुरुवात झाली.

कोरांवर असमान लोडचे उदाहरण.

अशी परिस्थिती देखील आहे (वरील आलेखाप्रमाणे) जेव्हा कोर असमानपणे लोड केले जातात आणि त्यापैकी काही 100% ची शिखरे असतात. फक्त एक कोर लोड केल्याप्रमाणे, CPU वापरासाठी अलार्म कार्य करणार नाही (ते संपूर्ण VM साठी आहे), परंतु कार्यप्रदर्शन समस्या असतील.

मी काय करावे? जर व्हर्च्युअल मशीनमधील सॉफ्टवेअर असमानपणे कोर लोड करत असेल (केवळ एक कोर किंवा कोरचा भाग वापरत असेल), तर त्यांची संख्या वाढवण्यात काही अर्थ नाही. या प्रकरणात, अधिक शक्तिशाली प्रोसेसर असलेल्या सर्व्हरवर व्हीएम हलविणे चांगले आहे.

तुम्ही सर्व्हर BIOS मध्ये वीज वापर सेटिंग्ज तपासण्याचा प्रयत्न देखील करू शकता. अनेक प्रशासक BIOS मध्ये उच्च कार्यप्रदर्शन मोड सक्षम करतात आणि त्याद्वारे C-स्टेट्स आणि P-स्टेट्स ऊर्जा बचत तंत्रज्ञान अक्षम करतात. आधुनिक इंटेल प्रोसेसर टर्बो बूस्ट तंत्रज्ञान वापरतात, जे इतर कोरच्या खर्चावर वैयक्तिक प्रोसेसर कोरची वारंवारता वाढवते. परंतु ऊर्जा बचत तंत्रज्ञान चालू असतानाच ते कार्य करते. आम्ही त्यांना अक्षम केल्यास, प्रोसेसर लोड नसलेल्या कोरचा वीज वापर कमी करू शकत नाही.

व्हीएमवेअर सर्व्हरवर पॉवर-सेव्हिंग तंत्रज्ञान अक्षम न करण्याची शिफारस करते, परंतु शक्य तितक्या हायपरवाइजरवर पॉवर व्यवस्थापन सोडणारे मोड निवडण्याची शिफारस करते. या प्रकरणात, हायपरवाइजर पॉवर वापर सेटिंग्जमध्ये, आपल्याला उच्च कार्यप्रदर्शन निवडण्याची आवश्यकता आहे.

तुमच्या इन्फ्रास्ट्रक्चरमध्ये वैयक्तिक VM (किंवा VM कोर) असल्यास ज्यांना CPU वारंवारता वाढवण्याची आवश्यकता असेल, तर विजेचा वापर योग्यरित्या समायोजित केल्याने त्यांच्या कार्यप्रदर्शनात लक्षणीय सुधारणा होऊ शकते.

CPU तयार

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

विश्लेषण कसे करावे? सामान्यतः, जर व्हर्च्युअल मशीनचे कोर 10% पेक्षा जास्त वेळा तयार स्थितीत असतील, तर तुम्हाला कार्यप्रदर्शन समस्या लक्षात येतील. सोप्या भाषेत सांगायचे तर, 10% पेक्षा जास्त वेळ VM भौतिक संसाधने उपलब्ध होण्याची प्रतीक्षा करते.

vCenter मध्ये तुम्ही CPU रेडीशी संबंधित 2 काउंटर पाहू शकता:

• तयारी,
• तयार.

दोन्ही काउंटरची मूल्ये संपूर्ण VM आणि वैयक्तिक कोरसाठी दोन्ही पाहिली जाऊ शकतात.
तत्परता टक्केवारी म्हणून ताबडतोब मूल्य दर्शवते, परंतु केवळ रिअल-टाइममध्ये (शेवटच्या तासासाठी डेटा, मापन मध्यांतर 20 सेकंद). "टाचांवर गरम" समस्या शोधण्यासाठी हे काउंटर वापरणे चांगले.

तयार काउंटर मूल्ये देखील ऐतिहासिक दृष्टीकोनातून पाहिली जाऊ शकतात. हे नमुने स्थापित करण्यासाठी आणि समस्येचे सखोल विश्लेषण करण्यासाठी उपयुक्त आहे. उदाहरणार्थ, एखाद्या व्हर्च्युअल मशीनला ठराविक वेळी कार्यप्रदर्शन समस्या येऊ लागल्यास, तुम्ही सीपीयू रेडी व्हॅल्यूच्या मध्यांतरांची तुलना सर्व्हरवरील एकूण लोडशी करू शकता जिथे हे व्हीएम चालू आहे आणि लोड कमी करण्यासाठी उपाय करू शकता (जर डीआरएस अयशस्वी).

रेडी, रेडिनेसच्या विपरीत, टक्केवारीत नाही तर मिलिसेकंदांमध्ये दर्शविले जाते. हा एक समेशन प्रकार काउंटर आहे, म्हणजेच, मापन कालावधी दरम्यान VM कोर तयार स्थितीत किती काळ होता हे दर्शविते. तुम्ही साधे सूत्र वापरून हे मूल्य टक्केवारीत रूपांतरित करू शकता:

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

उदाहरणार्थ, खालील आलेखामधील VM साठी, संपूर्ण व्हर्च्युअल मशीनसाठी पीक रेडी मूल्य खालीलप्रमाणे असेल:

तयार टक्केवारीची गणना करताना, आपण दोन मुद्द्यांकडे लक्ष दिले पाहिजे:

• संपूर्ण VM साठी रेडी व्हॅल्यू ही संपूर्ण कोरमधील रेडीची बेरीज आहे.
• मापन अंतराल. रिअल-टाइमसाठी ते 20 सेकंद आहे आणि, उदाहरणार्थ, दैनिक चार्टवर ते 300 सेकंद आहे.

सक्रिय समस्यानिवारणाने, हे साधे मुद्दे सहज गमावले जाऊ शकतात आणि अस्तित्वात नसलेल्या समस्यांचे निराकरण करण्यात मौल्यवान वेळ वाया जाऊ शकतो.

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

मी काय करावे? उच्च तयार मूल्य सूचित करते की वर्च्युअल मशीनच्या सामान्य ऑपरेशनसाठी सर्व्हरकडे पुरेसे प्रोसेसर संसाधने नाहीत. अशा परिस्थितीत, प्रोसेसर (vCPU:pCPU) द्वारे ओव्हरसबस्क्रिप्शन कमी करणे बाकी आहे. अर्थात, विद्यमान VM चे पॅरामीटर्स कमी करून किंवा VM चा काही भाग इतर सर्व्हरवर स्थलांतरित करून हे साध्य केले जाऊ शकते.

को-स्टॉप

विश्लेषण कसे करावे? हा काउंटर देखील समेशन प्रकाराचा आहे आणि तयार प्रमाणेच टक्केवारीत रूपांतरित केला जातो:

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

येथे आपल्याला व्हीएमवरील कोरची संख्या आणि मापन अंतरालकडे देखील लक्ष देणे आवश्यक आहे.
कॉस्टॉप स्थितीत, कर्नल उपयुक्त कार्य करत नाही. सर्व्हरवरील VM आकार आणि सामान्य लोडच्या योग्य निवडीसह, को-स्टॉप काउंटर शून्याच्या जवळ असावे.

या प्रकरणात, भार स्पष्टपणे असामान्य आहे :)

मी काय करावे? जर एका हायपरवाइजरवर मोठ्या संख्येने कोर असलेले अनेक VM चालू असतील आणि CPU वर ओव्हरसबस्क्रिप्शन असेल, तर को-स्टॉप काउंटर वाढू शकतो, ज्यामुळे या VM च्या कार्यक्षमतेत समस्या निर्माण होतील.

तसेच, एका VM चे सक्रिय कोर हायपर-ट्रेडिंग सक्षम असलेल्या एका भौतिक सर्व्हर कोरवर थ्रेड वापरल्यास सह-विराम वाढेल. ही परिस्थिती उद्भवू शकते, उदाहरणार्थ, जर VM मध्ये ते चालत असलेल्या सर्व्हरवर भौतिकदृष्ट्या उपलब्ध पेक्षा जास्त कोर असतील किंवा VM साठी “preferHT” सेटिंग सक्षम असेल तर. आपण या सेटिंगबद्दल वाचू शकता येथे.

उच्च सह-स्टॉपमुळे VM कार्यप्रदर्शनातील समस्या टाळण्यासाठी, या VM वर चालणाऱ्या सॉफ्टवेअरच्या निर्मात्याच्या शिफारसी आणि VM चालणाऱ्या भौतिक सर्व्हरच्या क्षमतांनुसार VM आकार निवडा.

रिझर्व्हमध्ये कोर जोडू नका; यामुळे केवळ व्हीएमसाठीच नाही तर सर्व्हरवरील त्याच्या शेजाऱ्यांसाठी देखील कार्यप्रदर्शन समस्या उद्भवू शकतात.

इतर उपयुक्त CPU मेट्रिक्स

चालवा - मापन कालावधी दरम्यान vCPU किती वेळ (ms) RUN स्थितीत होते, म्हणजेच ते प्रत्यक्षात उपयुक्त कार्य करत होते.

निष्क्रिय - मापन कालावधी दरम्यान किती काळ (ms) vCPU निष्क्रिय स्थितीत होता. उच्च निष्क्रिय मूल्ये ही समस्या नाही, vCPU ला फक्त "काहीच करायचे नव्हते."

प्रतीक्षा - मापन कालावधीत किती वेळ (ms) vCPU प्रतीक्षा स्थितीत होते. IDLE या काउंटरमध्ये समाविष्ट असल्याने, उच्च प्रतीक्षा मूल्ये देखील समस्या दर्शवत नाहीत. पण जर Wait जास्त असेल तेव्हा Wait IDLE कमी असेल, तर याचा अर्थ VM I/O ऑपरेशन्स पूर्ण होण्याची वाट पाहत होता, आणि यामुळे, हार्ड ड्राइव्ह किंवा VM च्या कोणत्याही व्हर्च्युअल डिव्हाइसेसच्या कार्यप्रदर्शनात समस्या सूचित होऊ शकते.

कमाल मर्यादित - सेट केलेल्या संसाधन मर्यादेमुळे मोजमाप कालावधीत किती काळ (ms) vCPU तयार स्थितीत होता. कार्यप्रदर्शन स्पष्टपणे कमी असल्यास, या काउंटरचे मूल्य आणि VM सेटिंग्जमध्ये CPU मर्यादा तपासणे उपयुक्त आहे. VM मध्ये खरोखर मर्यादा असू शकतात ज्याची तुम्हाला माहिती नाही. उदाहरणार्थ, जेव्हा CPU मर्यादा सेट केलेल्या टेम्पलेटवरून VM क्लोन केले जाते तेव्हा असे होते.

स्वॅप प्रतीक्षा - मापन कालावधी दरम्यान vCPU ने VMkernel Swap सह ऑपरेशनसाठी किती वेळ प्रतीक्षा केली. जर या काउंटरची मूल्ये शून्यापेक्षा जास्त असतील तर, व्हीएममध्ये निश्चितपणे कार्यप्रदर्शन समस्या आहेत. आम्ही RAM काउंटर बद्दल लेखात SWAP बद्दल अधिक बोलू.

ESXTOP

ऐतिहासिक डेटाचे विश्लेषण करण्यासाठी vCenter मधील कार्यप्रदर्शन काउंटर चांगले असल्यास, ESXTOP मध्ये समस्येचे ऑपरेशनल विश्लेषण अधिक चांगले केले जाते. येथे, सर्व मूल्ये तयार स्वरूपात सादर केली जातात (काहीही भाषांतरित करण्याची आवश्यकता नाही), आणि किमान मापन कालावधी 2 सेकंद आहे.
CPU साठी ESXTOP स्क्रीन "c" की सह कॉल केली जाते आणि ती यासारखी दिसते:

सोयीसाठी, तुम्ही Shift-V दाबून फक्त आभासी मशीन प्रक्रिया सोडू शकता.
वैयक्तिक VM कोरसाठी मेट्रिक्स पाहण्यासाठी, "e" दाबा आणि स्वारस्य असलेल्या VM चा GID प्रविष्ट करा (खालील स्क्रीनशॉटमध्ये 30919):

मी मुलभूतरित्या सादर केलेले स्तंभ थोडक्यात पाहू. "f" दाबून अतिरिक्त स्तंभ जोडले जाऊ शकतात.

NWLD (जगांची संख्या) - गटातील प्रक्रियांची संख्या. गटाचा विस्तार करण्यासाठी आणि प्रत्येक प्रक्रियेसाठी मेट्रिक्स पाहण्यासाठी (उदाहरणार्थ, मल्टी-कोर VM मधील प्रत्येक कोरसाठी), “e” दाबा. समूहात एकापेक्षा जास्त प्रक्रिया असल्यास, गटासाठी मेट्रिक मूल्ये वैयक्तिक प्रक्रियेच्या मेट्रिक्सच्या बेरजेइतकी असतात.

%वापरले - प्रक्रिया किंवा प्रक्रियांच्या गटाद्वारे किती सर्व्हर CPU चक्र वापरले जातात.

% RUN - मापन कालावधी दरम्यान प्रक्रिया RUN स्थितीत किती काळ होती, उदा. उपयुक्त काम केले. हे %USED पेक्षा वेगळे आहे कारण ते हायपर-थ्रेडिंग, फ्रिक्वेन्सी स्केलिंग आणि सिस्टम टास्क (%SYS) वर घालवलेला वेळ विचारात घेत नाही.

%SYS – सिस्टम टास्कमध्ये घालवलेला वेळ, उदाहरणार्थ: इंटरप्ट प्रोसेसिंग, I/O, नेटवर्क ऑपरेशन इ. जर VM मध्ये I/O मोठा असेल तर मूल्य जास्त असू शकते.

% OVRLP – ज्या भौतिक कोरवर VM प्रक्रिया चालू आहे तो इतर प्रक्रियेच्या कामांवर किती वेळ घालवतो.

हे मेट्रिक्स एकमेकांशी खालीलप्रमाणे संबंधित आहेत:

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

सामान्यतः %USED मेट्रिक अधिक माहितीपूर्ण असते.

% प्रतीक्षा करा - मापन कालावधी दरम्यान प्रक्रिया किती काळ प्रतीक्षा स्थितीत होती. IDLE सक्षम करते.

% निष्क्रिय - मापन कालावधी दरम्यान प्रक्रिया किती काळ IDLE स्थितीत होती.

%SWPWT - मापन कालावधी दरम्यान vCPU ने VMkernel Swap सह ऑपरेशनसाठी किती वेळ प्रतीक्षा केली.

%VMWAIT - मापन कालावधी दरम्यान vCPU एखाद्या इव्हेंटची वाट पाहण्याच्या स्थितीत किती काळ होता (सामान्यतः I/O). vCenter मध्ये समान काउंटर नाही. उच्च मूल्ये VM वर I/O सह समस्या दर्शवतात.

% प्रतीक्षा = % VMWAIT + % निष्क्रिय + % SWPWT.

जर VM VMkernel स्वॅप वापरत नसेल, तर कार्यप्रदर्शन समस्यांचे विश्लेषण करताना %VMWAIT कडे पाहण्याचा सल्ला दिला जातो, कारण हे मेट्रिक VM काहीही करत नव्हते तेव्हाची वेळ विचारात घेत नाही (%IDLE).

%RDY - मापन कालावधी दरम्यान प्रक्रिया किती काळ तयार स्थितीत होती.

%CSTP - मापन कालावधी दरम्यान प्रक्रिया किती काळ कॉस्टॉप स्थितीत होती.

%MLMTD - सेट केलेल्या संसाधन मर्यादेमुळे मोजमाप कालावधी दरम्यान किती काळ vCPU तयार स्थितीत होता.

% WAIT + % RDY + % CSTP + % RUN = 100% - VM कोर नेहमी या चार अवस्थांपैकी एका स्थितीत असतो.

हायपरवाइजरवर CPU

vCenter मध्ये हायपरवाइजरसाठी CPU कार्यप्रदर्शन काउंटर देखील आहेत, परंतु ते काही मनोरंजक नाहीत - ते फक्त सर्व्हरवरील सर्व VM साठी काउंटरची बेरीज आहेत.
सर्व्हरवरील CPU स्थिती पाहण्याचा सर्वात सोयीस्कर मार्ग म्हणजे सारांश टॅब:

सर्व्हरसाठी, तसेच व्हर्च्युअल मशीनसाठी, एक मानक अलार्म आहे:

जेव्हा सर्व्हरचा CPU लोड जास्त असतो, तेव्हा त्यावर चालणाऱ्या VM ला कार्यप्रदर्शन समस्या येऊ लागतात.

ESXTOP मध्ये, सर्व्हर CPU लोड डेटा स्क्रीनच्या शीर्षस्थानी सादर केला जातो. मानक CPU लोड व्यतिरिक्त, जे हायपरवाइझर्ससाठी फार माहितीपूर्ण नाही, आणखी तीन मेट्रिक्स आहेत:

कोर UTIL(%) - भौतिक सर्व्हर कोर लोड करत आहे. हे काउंटर मापन कालावधी दरम्यान कोरने किती वेळ काम केले हे दर्शविते.

PCPU UTIL(%) - हायपर-थ्रेडिंग सक्षम केले असल्यास, प्रत्येक भौतिक कोरमध्ये दोन थ्रेड्स (PCPU) असतात. हे मेट्रिक दाखवते की प्रत्येक थ्रेडने काम पूर्ण करण्यासाठी किती वेळ घेतला.

PCPU वापरला(%) – PCPU UTIL(%) प्रमाणेच, परंतु फ्रिक्वेंसी स्केलिंग (एकतर ऊर्जा बचतीच्या उद्देशाने कोर वारंवारता कमी करणे किंवा टर्बो बूस्ट तंत्रज्ञानामुळे कोर वारंवारता वाढवणे) आणि हायपर-थ्रेडिंग लक्षात घेते.

PCPU_USED% = PCPU_UTIL% * प्रभावी कोर वारंवारता / नाममात्र कोर वारंवारता.

या स्क्रीनशॉटमध्ये, काही कोरसाठी, टर्बो बूस्टमुळे, USED मूल्य 100% पेक्षा जास्त आहे, कारण कोर वारंवारता नाममात्रापेक्षा जास्त आहे.

हायपर-थ्रेडिंग कसे विचारात घेतले जाते याबद्दल काही शब्द. सर्व्हरच्या फिजिकल कोरच्या दोन्ही थ्रेडवर 100% वेळेत प्रक्रिया अंमलात आणल्या गेल्या असल्यास, कोर नाममात्र वारंवारतेवर कार्य करत असल्यास, नंतर:

• कोरसाठी CORE UTIL 100% असेल,
• दोन्ही थ्रेडसाठी PCPU UTIL 100% असेल,
• दोन्ही थ्रेडसाठी वापरलेला PCPU 50% असेल.

मापन कालावधी दरम्यान दोन्ही थ्रेड्सने 100% वेळ काम केले नाही, तर त्या कालावधीत जेव्हा थ्रेड्स समांतरपणे काम करत होते, तेव्हा कोरसाठी वापरलेला PCPU अर्ध्या भागात विभागला जातो.

ESXTOP मध्ये सर्व्हर CPU पॉवर वापर पॅरामीटर्ससह स्क्रीन देखील आहे. सर्व्हर ऊर्जा बचत तंत्रज्ञान वापरतो की नाही ते येथे तुम्ही पाहू शकता: सी-स्टेट्स आणि पी-स्टेट्स. "p" की सह कॉल केले:

सामान्य CPU कार्यप्रदर्शन समस्या

शेवटी, मी व्हीएम सीपीयू कार्यप्रदर्शनातील समस्यांच्या विशिष्ट कारणांवर जाईन आणि त्यांचे निराकरण करण्यासाठी लहान टिपा देईन:

कोर घड्याळ गती पुरेशी नाही. तुमचे VM अधिक शक्तिशाली कोरमध्ये अपग्रेड करणे शक्य नसल्यास, टर्बो बूस्ट अधिक कार्यक्षमतेने कार्य करण्यासाठी तुम्ही पॉवर सेटिंग्ज बदलण्याचा प्रयत्न करू शकता.

चुकीचे VM आकारमान (खूप जास्त/खूप कमी कोर). तुम्ही काही कोर इन्स्टॉल केल्यास, VM वर जास्त CPU लोड असेल. भरपूर असल्यास, उच्च सह-स्टॉप पकडा.

सर्व्हरवर CPU ची मोठी ओव्हरसबस्क्रिप्शन. व्हीएममध्ये उच्च रेडी असल्यास, सीपीयू ओव्हरसबस्क्रिप्शन कमी करा.

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

माझ्यासाठी CPU बद्दल एवढेच आहे. प्रश्न विचारा. पुढच्या भागात मी 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