VMware में कितना विवाद है?


21

अब कुछ समय के लिए मैं यह जानने की कोशिश कर रहा हूं कि हमारे कुछ व्यवसायिक-महत्वपूर्ण सिस्टमों में हल्के से लेकर चरम तक "सुस्ती" की खबरें क्यों आ रही हैं। मैंने हाल ही में VMware पर्यावरण के लिए अपनी आंखें बदल ली हैं, जहां प्रश्न में सभी सर्वर होस्ट हैं।

मैंने हाल ही में SCOM 2012 के लिए Veeam VMware प्रबंधन पैक के लिए परीक्षण डाउनलोड किया और स्थापित किया है, लेकिन मैं एक कठिन समय मान रहा हूं (और इसलिए मेरा बॉस है) यह मेरे लिए रिपोर्ट कर रहे हैं। अपने बॉस को यह समझाने का प्रयास करने के लिए कि जो संख्याएँ मुझे बता रही हैं, वे सच हैं, मैंने परिणामों को सत्यापित करने के लिए खुद VMware क्लाइंट को देखना शुरू किया।

मैंने इस VMware KB लेख को देखा है ; सह-रोक की परिभाषा के लिए विशेष रूप से परिभाषित किया गया है:

एक MP वर्चुअल मशीन चलाने के लिए कितनी बार तैयार हुई, लेकिन सह-वीसीपीयू शेड्यूलिंग विवाद के कारण देरी हुई

जिसका मैं अनुवाद कर रहा हूं

अतिथि OS को होस्ट से समय चाहिए, लेकिन संसाधनों के उपलब्ध होने की प्रतीक्षा करनी होगी और इसलिए उसे "अनुत्तरदायी" माना जा सकता है

क्या यह अनुवाद सही लगता है?

यदि ऐसा है, तो यहां मुझे एक कठिन समय है जो मुझे दिखाई दे रहा है: मेजबान जिसमें "धीमी" वीएम का बहुमत है, वर्तमान में 127,835.94 मिलीसेकंड का CPU सह-रोक औसत दिखा रहा है !

क्या इसका मतलब है कि इस होस्ट पर औसतन वीपीयू को सीपीयू समय के लिए 2+ मिनट इंतजार करना होगा ???

इस होस्ट में दो 4 कोर सीपीयू हैं और इसमें 1x8 सीपीयू गेस्ट और 14x4 सीपीयू मेहमान हैं।


मेरी समझ से: कुछ समस्याओं से बचने के लिए एक ही समय में एक वीएम के सभी वर्चुअल सीपीयू को चलाने के लिए निर्धारित किया जाता है। यदि कोई विवाद है तो कुछ वीएम वास्तव में धीरे-धीरे चल सकते हैं। ध्यान दें कि जब यह समस्या है तो हालात और बदतर हो जाएंगे।
ब्रायन

इस होस्ट में दो 4 कोर सीपीयू हैं और इसमें 1x8 सीपीयू गेस्ट और 14x4 सीपीयू मेहमान हैं।
चक

क्यों इतने सारे मेहमानों में 4 vCPU कॉन्फ़िगरेशन हैं?
ewwhite

6
CPU सह-शेड्यूलिंग विवाद आपको मार रहा है। वीसीपीयू की संख्या को कम करने या उस प्रणाली से कुछ वीएम को स्थानांतरित करने की आवश्यकता है।
ब्रायन

@ChuckHerrington आपको किसी उत्तर का अनुसरण करना या चिन्हित करना चाहिए।
इविहित

जवाबों:


17

मैं इस क्षेत्र में किए गए कुछ अनुभवों का वर्णन कर सकता हूं ...

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

ओपी के लिए, ईएसएक्सआई होस्ट सर्वर में दो क्वाड-कोर सीपीयू हैं, जो 8 भौतिक कोर की उपज है।

वर्चुअल मशीन लेआउट का वर्णन किया जा रहा है, जो कुल 15 मेहमान हैं; 1 एक्स 8 वीसीपीयू और 14 एक्स 4 वीसीपीयू सिस्टम। यह तरीका बहुत अधिक है, विशेष रूप से 8 vCPUs के साथ एक ही अतिथि के अस्तित्व के साथ । इसका कोई मतलब नही बनता। यदि आपको एक वीएम की आवश्यकता है, तो आपको बड़े सर्वर की आवश्यकता है।

कृपया अपनी वर्चुअल मशीनों को सही आकार देने का प्रयास करें । मुझे पूरा यकीन है कि उनमें से अधिकांश 2 वीसीपीयू के साथ रह सकते हैं। वर्चुअल सीपीयू जोड़ने से चीजें तेजी से नहीं चलती हैं, इसलिए यदि यह प्रदर्शन समस्या का एक उपाय है, तो यह गलत तरीका है।

अधिकांश वातावरण में, RAM सबसे अधिक विवश संसाधन है। लेकिन बहुत अधिक विवाद होने पर सीपीयू एक समस्या हो सकती है। इसके प्रमाण आपके पास हैं। यदि कोई व्यक्ति VM को बहुत अधिक आवंटित करता है, तो RAM भी एक समस्या हो सकती है

इसकी निगरानी संभव है। जिस मीट्रिक की आप तलाश कर रहे हैं वह "CPU रेडी%" है। तुम एक वी एम का चयन और के लिए जा रहा द्वारा vSphere ग्राहक से उपयोग कर सकते हैं Performance> Overview> सीपीयू ग्राफ़।

  • 5% CPU रेडी के तहत - आप ठीक हैं।
  • 5-10% सीपीयू तैयार - गतिविधि पर कड़ी नजर रखें।
  • 10% से अधिक CPU तैयार - अच्छा नहीं।

नीचे दिए गए ग्राफ़ में येलो लाइन पर ध्यान दें। यहां छवि विवरण दर्ज करें

क्या आप अपनी समस्या पर वर्चुअल मशीन और वापस रिपोर्ट करने पर यह जाँच करेंगे?


बस एक एक्सचेंज सर्वर के लिए ग्राफ को देखा है जो हमारे पास उस ओवरकमेज़्ड होस्ट पर है। मेरा ग्राफ आपका उलटा दिखता है। CPU उपयोग लगभग 25% और CPU रेडी स्पाइक्स को 200% तक बढ़ाता है, लेकिन औसतन लगभग 100% है।
चक हेरिंगटन

@ChuckHerrington कृपया 8 वीसीपीयू वर्चुअल मशीन के संसाधनों को कम करें और फिर से मापें।
ewwhite

8 cpu अतिथि के साथ एकमात्र चिंता मुख्य उत्पादन sql सर्वर डेटाबेस सर्वरों में से एक है। हमने इससे पहले 4 को कम करने की कोशिश की थी और चीजें आगे बढ़ गईं ... घबरा गईं। लगता है हम बेहतर फिर से कोशिश करते हैं।
चक हेरिंगटन

आपके पास कुल 8 कोर वाले सर्वर पर 8 वीसीपीयू वर्चुअल मशीन नहीं हो सकती है।
ewwhite

@ दुर्भाग्य से आप कर सकते हैं, आप नहीं करना चाहिए, लेकिन आप कर सकते हैं।
राकोमी

46

आप टिप्पणी में कहते हैं कि आपके पास एक दोहरी क्वाड-कोर ईएसएक्सआई होस्ट है, और आप एक 8vCPU VM, और चौदह 4vCPU VMs चला रहे हैं ।

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

मैं मान रहा हूं कि आपको सुनहरा नियम नहीं पता है ... वीएमवेयर के साथ आपको कभी भी जरूरत से ज्यादा वीएम को आवंटित नहीं करना चाहिए। कारण? VMware कुछ सख्त सह-शेड्यूलिंग का उपयोग करता है जो VMs को CPU समय प्राप्त करने के लिए कठिन बनाता है जब तक कि वीएम को असाइन किए गए कई कोर उपलब्ध नहीं हैं। मतलब, एक 4vCPU VM 1 यूनिट कार्य नहीं कर सकता है जब तक कि एक ही समय में 4 भौतिक कोर खुले न हों। दूसरे शब्दों में, 90% CPU लोड के साथ 1vCPU VM का होना बेहतर है, फिर 2vCPU VM को 45% लोड प्रति कोर के साथ रखना है।

इसलिए ... हमेशा कम से कम वीसीपीयू के साथ वीएम बनाएं, और केवल जब आवश्यक हो तो उन्हें जोड़ें।

अपनी स्थिति के लिए, अपने मेहमानों पर सीपीयू के उपयोग की निगरानी के लिए वीम का उपयोग करें। वीसीपीयू की गिनती को यथासंभव कम करें। मैं शर्त लगाने को तैयार हूं कि आप अपने सभी मौजूदा 4vCPU मेहमानों पर 2vCPU छोड़ सकते हैं।

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


20
यह जवाब, मुझे यह पसंद है, एक और! (जमीन पर कॉफी कप स्मैश करता है)
मंकीज़े

2
जोड़ने के लिए एक बात .. CPU% तैयार के लिए एक चेतावनी सेट करें। davidklee.net/articles/sql-server-articles/…
Stewpudaso

1
क्या यह प्रावधान के तहत नहीं होना चाहिए?
user253751

3
क्या वह VMWare मूर्खता अभी भी जगह में है? हाइपर-वी की शुरुआती संस्करण में समान थी और इसे जल्द से जल्द संभाल लिया गया था। अब कोर स्वतंत्र रूप से निर्धारित हैं। मैं वर्तमान संस्करण में VmWare के लिए अभी भी ऐसा होने की कल्पना नहीं कर सकता।
टॉमटॉम

2
@TomTom: serverfault.com/a/642316/58957 के अनुसार "सख्त सह-शेड्यूलिंग" को 3.x (10 साल से अधिक पहले!) से पहले के संस्करणों में नियोजित किया गया था, फिर भी इंटरनेट अभी भी इससे भरा हुआ है। फिर भी केवल आवश्यक vCPUs की संख्या बढ़ाने के लिए सिफारिश ध्वनि है।
निकोले

2

127,835.94 मिलीसेकंड एक योग है और आपको सही% RDY मान प्राप्त करने के लिए नमूना समय से विभाजित करने की आवश्यकता है। ऐसा लगता है कि आप पहले से ही सही% RDY रीडिंग अभी प्राप्त कर रहे हैं। आप भौतिक सीपीयू अनुपात के लिए वीसीपीयू के साथ काफी अधिक जा सकते हैं लेकिन जिस तरह से आप कर रहे हैं वह नहीं।

आपके पास बहुत सारे ट्रैक्टर vCPU VM और यहां तक ​​कि 8 vCPU VM भी हैं। कुछ गुणवत्ता प्रतिक्रियाएं पहले से ही राइट-साइज़िंग पर चर्चा कर रही हैं और कम वीसीपीयू के लिए चक्रों को समेकित नहीं करने के कुछ प्रभाव हैं। एक बात जो मैं स्पष्ट करना चाहता था, वह यह है कि अब वह स्थिति नहीं है कि किसी वीएम को भौतिक सीपीयू की संख्या का इंतजार करना चाहिए, जो किसी भी निर्देश पर कार्रवाई किए जाने से पहले उपलब्ध होने के लिए वीसीपीयू की संख्या के बराबर है, यह बहुत हानिकारक है भौतिक वाहिकाओं के लिए बहु-वीसीपीयू वीएम के अनुपात के साथ इस परिमाण का अधिक प्रावधान करना। 8 कोर पर 64 वीसीपीयू अधिकतम 4 से 1 के अनुपात से परे है। मुझे लगता है कि आपके पास इन प्रोसेसर पर एचटी है तो आपके पास 16 तार्किक कोर हैं? यह 1 और 2 वीसीपीयू वीएम के साथ ठीक हो सकता है जिनके पास हल्का भार है लेकिन अगर आपके पास वीएम पर भारी भार है तो इसे पूरा करना मुश्किल होगा।

FYI करें HT प्रोसेसर का उपयोग CPU% की गणना में नहीं किया जाता है - यदि आपके पास सर्वर पर 2.4 Ghz पर 32 तार्किक कोर चल रहा है, तो आप 38.4 GHz हिट करने पर 100% उपयोग में हैं। इसलिए जब आप लोड औसत को 1.0 से अधिक दिखा रहे हैं, यही कारण है।

यहाँ एक ESXi होस्ट है जो कि 3.5 से 1 vCPU से भौतिक CPU (HT cores सहित) का औसत% RDY 3% से चल रहा है।

11:13:49pm up 125 days  7:20, 1322 worlds, 110 VMs, 110 vCPUs; CPU load average: 1.34, 1.43, 1.37


  %USED    %RUN    %SYS   %WAIT %VMWAIT    %RDY   %IDLE  %OVRLP   %CSTP  %MLMTD  %SWPWT 
  13.51   15.87    0.50  580.17    0.03    4.67   66.47    0.29    0.00    0.00    0.00 
  15.24   18.64    0.43  491.54    0.04    4.65   63.70    0.43    0.00    0.00    0.00 
  13.44   16.40    0.44  494.10    0.02    4.33   66.24    0.48    0.00    0.00    0.00 
  13.75   16.30    0.51  494.26    0.32    4.32   66.06    0.35    0.00    0.00    0.00 
  17.56   20.72    0.58  489.35    0.04    4.31   60.76    0.45    0.00    0.00    0.00 
  13.82   16.43    0.50  494.12    0.07    4.31   66.26    0.26    0.00    0.00    0.00 
  13.65   16.81    0.49  493.81    0.03    4.21   65.93    0.37    0.00    0.00    0.00 
  13.73   16.51    0.42  493.63    0.09    4.06   66.24    0.29    0.00    0.00    0.00 
  13.89   16.37    0.55  580.61    0.04    3.95   66.69    0.28    0.00    0.00    0.00 
  14.02   17.00    0.33  494.11    0.03    3.93   66.10    0.29    0.00    0.00    0.00 
  13.44   15.84    0.49  495.17    0.04    3.87   67.24    0.27    0.00    0.00    0.00 
  13.59   15.84    0.50  580.27    0.04    3.81   67.24    0.44    0.00    0.00    0.00 
  17.10   19.86    0.50  490.97    0.04    3.74   62.21    0.39    0.00    0.00    0.00 
  13.32   15.77    0.50  495.34    0.03    3.73   67.47    0.27    0.00    0.00    0.00 
  13.43   16.15    0.48  494.95    0.05    3.72   67.09    0.38    0.00    0.00    0.00 
  13.44   16.47    0.49  580.88    0.04    3.72   66.81    0.40    0.00    0.00    0.00 
  13.71   17.00    0.29  494.13    0.03    3.71   66.26    0.37    0.00    0.00    0.00 
  17.34   20.41    0.39  490.50    0.05    3.70   61.70    0.37    0.00    0.00    0.00 
  13.42   16.19    0.50  495.07    0.03    3.66   67.15    0.38    0.00    0.00    0.00 
  13.56   16.23    0.48  494.97    0.03    3.60   67.12    0.30    0.00    0.00    0.00 
  14.95   17.53    0.42  578.82    0.09    3.57   65.72    0.35    0.00    0.00    0.00 
  13.44   16.07    0.56  581.14    0.04    3.54   67.34    0.40    0.00    0.00    0.00 
  17.19   21.27    0.37  575.41    0.04    3.44   61.08    0.51    0.00    0.00    0.00 
  13.57   16.99    0.30  580.64    0.01    3.37   66.69    0.38    0.00    0.00    0.00 
  13.79   16.25    0.43  495.25    0.04    3.35   67.39    0.39    0.00    0.00    0.00 
  11.90   14.67    0.30  496.86    0.02    3.31   69.00    0.36    0.00    0.00    0.00 
  17.13   19.28    0.56  491.83    0.03    3.30   63.26    0.48    0.00    0.00    0.00 
  14.01   16.17    0.50  495.56    0.01    3.30   67.66    0.39    0.00    0.00    0.00 
  16.86   20.16    0.57  491.19    0.05    3.20   62.44    0.43    0.00    0.00    0.00 
  14.94   17.46    0.42  580.05    0.08    3.16   66.24    0.40    0.00    0.00    0.00 
  14.56   16.94    0.36  494.86    0.08    3.14   66.91    0.42    0.00    0.00    0.00

......

1

हमने तब से वीईएम वन स्थापित किया है, जहां हमारे प्रदर्शन के मुद्दों पर काफी प्रकाश डाला गया है। वीईएम वन में सीपीयू बॉटलनेक्स स्क्रीन को देख कर फिर एक वर्चुअल मशीन के समस्या निवारण का उपयोग करना , जिसने जवाब देना बंद कर दिया है: वीएमएम और गेस्ट सीपीयू के उपयोग की तुलना एक संदर्भ के रूप में की गई है, जहां हमने "अस्वीकार्य" विवाद का उल्लेख किया है।

एक छोटी सी टिप जिसे मैं विशेष रूप से साझा करना चाहता था वह यह है कि एक मामले में मैं सीपीयू विवाद को समाप्त नहीं कर सकता था जब तक कि मैं वीएमपी पर स्नैपशॉट को हटा नहीं देता। आशा है कि यह किसी की मदद करता है।


अरे मेरा। स्नैपशॉट चल रहे थे, भी?
ewwhite
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.