VMware vSphere मा भर्चुअल मेसिन प्रदर्शन को विश्लेषण। भाग १: CPU

यदि तपाइँ VMware vSphere (वा कुनै अन्य प्रविधि स्ट्याक) मा आधारित भर्चुअल पूर्वाधार व्यवस्थापन गर्नुहुन्छ भने, तपाइँ प्राय: प्रयोगकर्ताहरूबाट गुनासोहरू सुन्नुहुन्छ: "भर्चुअल मेसिन ढिलो छ!" लेखहरूको यस शृङ्खलामा म कार्यसम्पादन मेट्रिक्सको विश्लेषण गर्नेछु र के र किन यो ढिलो हुन्छ र यसलाई ढिलो नगर्ने कसरी सुनिश्चित गर्ने भनेर बताउनेछु।

म भर्चुअल मेसिन प्रदर्शनको निम्न पक्षहरूलाई विचार गर्नेछु:

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

म CPU बाट सुरु गर्नेछु।

कार्यसम्पादन विश्लेषण गर्न हामीलाई आवश्यक पर्दछ:

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

बिट सिद्धान्त

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

ESXi मा एक प्रक्रिया चार राज्यहरु मध्ये एक मा हुन सक्छ:

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

आधारभूत भर्चुअल मेसिन CPU प्रदर्शन काउन्टरहरू

CPU उपयोग, %। दिइएको अवधिको लागि CPU उपयोगको प्रतिशत देखाउँछ।

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

त्यहाँ एक मानक अलार्म छ जसले भर्चुअल मेसिनको CPU लोड देखाउँछ:

मैले के गर्नु पर्छ? यदि VM को CPU प्रयोग लगातार छत मार्फत जाँदैछ भने, त्यसपछि तपाइँ vCPU को संख्या बढाउने बारे सोच्न सक्नुहुन्छ (दुर्भाग्यवश, यसले सधैं मद्दत गर्दैन) वा VM लाई थप शक्तिशाली प्रोसेसरहरू भएको सर्भरमा सार्ने बारे सोच्न सक्नुहुन्छ।

MHz मा CPU उपयोग

% मा vCenter प्रयोगमा ग्राफहरूमा तपाईंले सम्पूर्ण भर्चुअल मेसिनको लागि मात्र देख्न सक्नुहुन्छ; त्यहाँ व्यक्तिगत कोरहरूको लागि कुनै ग्राफहरू छैनन् (Extop मा त्यहाँ कोरहरूको लागि % मानहरू छन्)। प्रत्येक कोर को लागी तपाईले MHz मा उपयोग देख्न सक्नुहुन्छ।

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

कोर मा असमान लोड को एक उदाहरण।

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

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

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

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

यदि तपाइँसँग तपाइँको पूर्वाधारमा व्यक्तिगत VM हरू (वा VM कोर) छन् जसलाई CPU फ्रिक्वेन्सी बढाउन आवश्यक छ भने, सही रूपमा बिजुली खपत समायोजनले तिनीहरूको कार्यसम्पादनमा उल्लेखनीय सुधार गर्न सक्छ।

CPU तयार छ

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

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

vCenter मा तपाईंले CPU तयारसँग सम्बन्धित 2 काउन्टरहरू हेर्न सक्नुहुन्छ:

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

दुबै काउन्टरहरूको मानहरू सम्पूर्ण VM र व्यक्तिगत कोरहरूको लागि दुवै हेर्न सकिन्छ।
तत्परताले प्रतिशतको रूपमा तुरुन्तै मान देखाउँछ, तर वास्तविक समयमा मात्र (अन्तिम घण्टाको लागि डाटा, मापन अन्तराल २० सेकेन्ड)। "हिलमा तातो" समस्याहरू खोज्नका लागि मात्र यो काउन्टर प्रयोग गर्नु राम्रो हो।

तयार काउन्टर मानहरू पनि ऐतिहासिक परिप्रेक्ष्यबाट हेर्न सकिन्छ। यो ढाँचाहरू स्थापना गर्न र समस्याको गहिरो विश्लेषणको लागि उपयोगी छ। उदाहरणका लागि, यदि भर्चुअल मेसिनले कुनै निश्चित समयमा कार्यसम्पादन समस्याहरू अनुभव गर्न थाल्छ भने, तपाईंले यो VM चलिरहेको सर्भरमा रहेको कुल लोडसँग CPU तयार मानको अन्तरालहरू तुलना गर्न सक्नुहुन्छ, र लोड घटाउन उपायहरू लिन सक्नुहुन्छ (यदि DRS असफल)।

तयार, तयारीको विपरीत, प्रतिशतमा होइन, मिलिसेकेन्डमा देखाइएको छ। यो एक समेशन प्रकार काउन्टर हो, त्यो हो, यसले मापन अवधिमा VM कोर तयार अवस्थामा कति लामो थियो भनेर देखाउँछ। तपाईले यो मानलाई साधारण सूत्र प्रयोग गरेर प्रतिशतमा रूपान्तरण गर्न सक्नुहुन्छ:

(CPU तयार योग मान / (सेकेन्डमा चार्ट पूर्वनिर्धारित अद्यावधिक अन्तराल * 1000)) * 100 = CPU तयार %

उदाहरणका लागि, तलको ग्राफमा VM को लागि, सम्पूर्ण भर्चुअल मेसिनको लागि शिखर तयार मान निम्नानुसार हुनेछ:

तयार प्रतिशत गणना गर्दा, तपाईंले दुई बिन्दुहरूमा ध्यान दिनुपर्छ:

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

सक्रिय समस्या निवारणको साथ, यी सरल बिन्दुहरू सजिलैसँग छुटाउन सकिन्छ र बहुमूल्य समय अस्तित्वहीन समस्याहरू समाधान गर्न बर्बाद गर्न सकिन्छ।

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

मैले के गर्नु पर्छ? उच्च तयार मानले सर्भरसँग भर्चुअल मेसिनहरूको सामान्य सञ्चालनका लागि पर्याप्त प्रोसेसर स्रोतहरू छैनन् भनी संकेत गर्छ। यस्तो अवस्थामा, प्रोसेसर (vCPU:pCPU) द्वारा ओभरसब्सक्रिप्शन कम गर्न बाँकी रहेको छ। जाहिर छ, यो अवस्थित VMs को प्यारामिटरहरू घटाएर वा VM को भागलाई अन्य सर्भरहरूमा स्थानान्तरण गरेर प्राप्त गर्न सकिन्छ।

को-स्टप

कसरी विश्लेषण गर्ने? यो काउन्टर पनि योग प्रकारको हो र तयार जस्तै प्रतिशतमा रूपान्तरण हुन्छ:

(CPU को-स्टप समेशन मान / (सेकेन्डमा चार्ट पूर्वनिर्धारित अद्यावधिक अन्तराल * 1000)) * 100 = CPU को-स्टप %

यहाँ तपाईंले VM मा कोरहरूको संख्या र मापन अन्तरालमा पनि ध्यान दिन आवश्यक छ।
कोस्टप अवस्थामा, कर्नेलले उपयोगी काम गर्दैन। सर्भरमा VM साइज र सामान्य लोडको सही चयनको साथ, को-स्टप काउन्टर शून्यको नजिक हुनुपर्छ।

यस अवस्थामा, लोड स्पष्ट रूपमा असामान्य छ :)

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

साथै, एक VM को सक्रिय कोरले हाइपर-ट्रेडिङ सक्षम भएको एउटा भौतिक सर्भर कोरमा थ्रेडहरू प्रयोग गरेमा सह-स्टप बढ्नेछ। यो अवस्था उत्पन्न हुन सक्छ, उदाहरणका लागि, यदि VM मा चलिरहेको सर्भरमा भौतिक रूपमा उपलब्ध भन्दा धेरै कोरहरू छन् भने, वा यदि VM को लागि "preferHT" सेटिङ सक्षम गरिएको छ। तपाईं यो सेटिङ बारे पढ्न सक्नुहुन्छ यहाँ.

उच्च सह-स्टपको कारणले VM कार्यसम्पादनमा समस्याहरूबाट बच्न, यो VM मा चल्ने सफ्टवेयरको निर्माताको सिफारिसहरू र VM चल्ने भौतिक सर्भरको क्षमताहरू अनुसार VM आकार चयन गर्नुहोस्।

रिजर्भमा कोरहरू थप नगर्नुहोस्; यसले VM को लागि मात्र होइन, तर सर्भरमा यसको छिमेकीहरूको लागि पनि प्रदर्शन समस्याहरू निम्त्याउन सक्छ।

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

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

निष्क्रिय - कति लामो (ms) मापन अवधिमा vCPU निष्क्रिय अवस्थामा थियो। उच्च निष्क्रिय मानहरू कुनै समस्या होइन, vCPU सँग "केही गर्न को लागी" थिएन।

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

अधिकतम सीमित - मापन अवधिमा कति लामो (ms) सेट स्रोत सीमाको कारण vCPU तयार अवस्थामा थियो। यदि कार्यसम्पादन स्पष्ट रूपमा कम छ भने, यो काउन्टरको मान र VM सेटिङहरूमा CPU सीमा जाँच गर्न उपयोगी छ। VM हरूमा वास्तवमै सीमाहरू हुन सक्छन् जुन तपाईंलाई थाहा छैन। उदाहरणका लागि, CPU सीमा सेट गरिएको टेम्प्लेटबाट VM क्लोन गर्दा यो हुन्छ।

प्रतिक्षा बदल्नुहोस् - मापन अवधिमा vCPU ले VMkernel Swap सँग सञ्चालनको लागि कति समय पर्ख्यो। यदि यस काउन्टरको मानहरू शून्य भन्दा माथि छन् भने, VM सँग निश्चित रूपमा प्रदर्शन समस्याहरू छन्। हामी RAM काउन्टरहरूको बारेमा लेखमा SWAP को बारेमा थप कुरा गर्नेछौं।

ESXTOP

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

सुविधाको लागि, तपाईंले Shift-V थिचेर भर्चुअल मेसिन प्रक्रियाहरू मात्र छोड्न सक्नुहुन्छ।
व्यक्तिगत VM कोरहरूको मेट्रिक्स हेर्न, "e" थिच्नुहोस् र रुचिको VM को GID प्रविष्ट गर्नुहोस् (तलको स्क्रिनसटमा 30919):

मलाई छोटकरीमा पूर्वनिर्धारित रूपमा प्रस्तुत गरिएका स्तम्भहरू मार्फत जान दिनुहोस्। "f" थिचेर थप स्तम्भहरू थप्न सकिन्छ।

NWLD (संसारको संख्या) - समूहमा प्रक्रियाहरूको संख्या। समूह विस्तार गर्न र प्रत्येक प्रक्रियाको मेट्रिक्स हेर्न (उदाहरणका लागि, बहु-कोर VM मा प्रत्येक कोरको लागि), "e" थिच्नुहोस्। यदि त्यहाँ एक समूहमा एक भन्दा बढी प्रक्रियाहरू छन् भने, समूहको लागि मेट्रिक मानहरू व्यक्तिगत प्रक्रियाहरूको लागि मेट्रिक्सको योग बराबर हुन्छन्।

% प्रयोग गरिएको - कति सर्भर CPU चक्र प्रक्रिया वा प्रक्रियाहरूको समूह द्वारा प्रयोग गरिन्छ।

% रन - मापन अवधिमा कति लामो प्रक्रिया RUN राज्यमा थियो, अर्थात्। उपयोगी काम गरे। यो %USED बाट फरक छ कि यसले हाइपर-थ्रेडिङ, फ्रिक्वेन्सी स्केलिङ र प्रणाली कार्यहरू (%SYS) मा खर्च गरेको समयलाई ध्यानमा राख्दैन।

% SYS - प्रणाली कार्यहरूमा खर्च गरिएको समय, उदाहरणका लागि: अवरोध प्रशोधन, I/O, नेटवर्क सञ्चालन, आदि। यदि VM सँग ठूलो I/O छ भने मूल्य उच्च हुन सक्छ।

% OVRLP - कति समय भौतिक कोर जसमा VM प्रक्रिया चलिरहेको छ अन्य प्रक्रियाहरूको कार्यहरूमा खर्च भयो।

यी मेट्रिकहरू निम्नानुसार एक अर्कासँग सम्बन्धित छन्:

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

सामान्यतया %USED मेट्रिक बढी जानकारीमूलक हुन्छ।

% पर्खनुहोस् - कति लामो समय मापन अवधि मा प्रक्रिया पर्ख राज्य मा थियो। IDLE सक्षम गर्दछ।

% IDLE - मापन अवधिमा कति लामो प्रक्रिया IDLE स्थितिमा थियो।

% SWPWT - मापन अवधिमा vCPU ले VMkernel Swap सँग सञ्चालनको लागि कति समय पर्ख्यो।

% VMWAIT - मापन अवधिमा vCPU घटना (सामान्यतया I/O) को लागि पर्खिरहेको अवस्थामा कति लामो थियो। vCenter मा कुनै समान काउन्टर छैन। उच्च मानहरूले VM मा I/O सँग समस्याहरू देखाउँछन्।

% WAIT = % VMWAIT + % निष्क्रिय + % SWPWT।

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

% RDY - मापन अवधिमा कति लामो प्रक्रिया तयार अवस्थामा थियो।

%CSTP - मापन अवधिमा कति लामो प्रक्रिया कोस्टप अवस्थामा थियो।

%MLMTD - सेट गरिएको स्रोत सीमाको कारणले मापन अवधिमा vCPU तयार अवस्थामा कति लामो थियो।

% WAIT + % RDY + % CSTP + % RUN = 100% - VM कोर सधैं यी चार राज्यहरू मध्ये एकमा हुन्छ।

हाइपरभाइजरमा CPU

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

सर्भरको लागि, साथै भर्चुअल मेसिनको लागि, त्यहाँ एक मानक अलार्म छ:

जब सर्भर CPU लोड उच्च हुन्छ, यसमा चलिरहेको VMs ले कार्यसम्पादन समस्याहरू अनुभव गर्न थाल्छ।

ESXTOP मा, सर्भर CPU लोड डाटा स्क्रिनको शीर्षमा प्रस्तुत गरिन्छ। मानक CPU लोडको अतिरिक्त, जुन हाइपरभाइजरहरूको लागि धेरै जानकारीपूर्ण छैन, त्यहाँ तीन थप मेट्रिकहरू छन्:

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

PCPU UTIL(%) - यदि हाइपर-थ्रेडिङ सक्षम छ भने, त्यहाँ प्रति भौतिक कोर दुई थ्रेडहरू (PCPU) छन्। यो मेट्रिकले प्रत्येक थ्रेडले काम पूरा गर्न कति समय लिएको देखाउँछ।

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

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

यस स्क्रिनसटमा, केही कोरहरूको लागि, टर्बो बूस्टको कारण, USED मान १००% भन्दा बढी छ, किनकि कोर फ्रिक्वेन्सी नाममात्र भन्दा बढी छ।

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

• कोरको लागि CORE UTIL 100% हुनेछ,
• दुबै थ्रेडहरूको लागि PCPU UTIL 100% हुनेछ,
• दुबै थ्रेडहरूको लागि प्रयोग गरिएको PCPU 50% हुनेछ।

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

ESXTOP सँग सर्भर CPU पावर खपत प्यारामिटरहरू सहितको स्क्रिन पनि छ। यहाँ तपाईँले सर्भरले ऊर्जा बचत प्रविधिहरू प्रयोग गर्दछ कि भनेर हेर्न सक्नुहुन्छ: C-राज्यहरू र P-राज्यहरू। "p" कुञ्जी संग कल गरिएको:

सामान्य CPU प्रदर्शन मुद्दाहरू

अन्तमा, म VM CPU प्रदर्शनको साथ समस्याहरूको विशिष्ट कारणहरूमा जानेछु र तिनीहरूलाई समाधान गर्न छोटो सुझावहरू दिनेछु:

कोर घडी गति पर्याप्त छैन। यदि तपाइँको VM लाई थप शक्तिशाली कोरहरूमा स्तरवृद्धि गर्न सम्भव छैन भने, तपाइँ टर्बो बूस्टलाई अझ प्रभावकारी रूपमा काम गर्न पावर सेटिङहरू परिवर्तन गर्ने प्रयास गर्न सक्नुहुन्छ।

गलत VM साइजिङ (धेरै धेरै/केही कोर)। यदि तपाईंले केही कोरहरू स्थापना गर्नुभयो भने, त्यहाँ VM मा उच्च CPU लोड हुनेछ। यदि त्यहाँ धेरै छ भने, उच्च को-स्टप समात्नुहोस्।

सर्भरमा CPU को ठूलो ओभरसब्सक्रिप्शन। यदि VM उच्च तयार छ भने, 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