VMware स्मृति प्रबंधन एक मुश्किल संतुलन अधिनियम लगता है। क्लस्टर रैम, रिसोर्स पूल, वीएमवेयर की प्रबंधन तकनीकों (टीपीएस, बैलूनिंग, होस्ट स्वैपिंग) के साथ, इन-गेस्ट रैम उपयोग, स्वैपिंग, आरक्षण, शेयर और सीमाएँ, बहुत सारे वैरिएबल हैं।
मैं ऐसी स्थिति में हूं जहां ग्राहक समर्पित vSphere क्लस्टर संसाधनों का उपयोग कर रहे हैं। हालाँकि, वे वर्चुअल मशीनों को कॉन्फ़िगर कर रहे हैं जैसे कि वे भौतिक हार्डवेयर पर थे। बदले में, इसका मतलब है कि मानक वीएम बिल्ड में 4 वीसीपीयू और 16 जीबी या अधिक रैम हो सकते हैं। मैं छोटी (1 वीसीपीयू, न्यूनतम रैम) शुरू करने के स्कूल से आता हूं, वास्तविक दुनिया के उपयोग की जांच कर रहा हूं और आवश्यकतानुसार समायोजित कर रहा हूं। दुर्भाग्य से, कई विक्रेता आवश्यकताएं और वर्चुअलाइजेशन से अपरिचित लोग आवश्यकता से अधिक संसाधनों का अनुरोध करते हैं ... मुझे इस निर्णय के प्रभाव को बढ़ाने में रुचि है।
"समस्या" क्लस्टर से कुछ उदाहरण।
संसाधन पूल सारांश - लगभग 4: 1 दिखता है। गुब्बारे की उच्च मात्रा पर ध्यान दें।
संसाधन आवंटन - सबसे खराब स्थिति आवंटन कॉलम से पता चलता है कि इन वीएम को विवश परिस्थितियों में अपने कॉन्फ़िगर किए गए रैम के 50% से कम तक पहुंच होगी।
ऊपर सूचीबद्ध में शीर्ष वीएम का वास्तविक समय मेमोरी उपयोग ग्राफ। 4 वीसीपीयू और 64 जीबी रैम आवंटित। यह 9GB उपयोग के तहत औसत है।
उसी वीएम का सारांश
ओवरस्मिटिंग और ओवरकॉन्फिगरिंग संसाधनों (विशेष रूप से रैम) के vsphere वातावरण में डाउनसाइड क्या हैं?
यह मानते हुए कि वीएम कम रैम में चल सकते हैं, क्या यह कहना उचित है कि वर्चुअल मशीनों को अधिक रैम के साथ कॉन्फ़िगर करने के लिए ओवरहेड है, जो वास्तव में उनकी आवश्यकता है?
प्रतिवाद क्या है: "अगर एक वीएम में 16 जीबी रैम आवंटित है, लेकिन केवल 4 जीबी का उपयोग करता है, तो समस्या क्या है? "? जैसे कि ग्राहकों को शिक्षित करने की आवश्यकता है कि वीएम भौतिक हार्डवेयर के समान नहीं हैं?
मीटर रैम के उपयोग के लिए क्या विशिष्ट मेट्रिक का उपयोग किया जाना चाहिए। "सक्रिय" बनाम समय की चोटियों पर नज़र रखना? "उपभोक्ता" देख रहे हैं?
अपडेट: मैंने इस वातावरण को प्रोफाइल करने और ऊपर सूचीबद्ध क्लस्टर आंकड़ों पर कुछ विवरण प्राप्त करने के लिए vCenter के संचालन प्रबंधक का उपयोग किया । हालांकि चीजें निश्चित रूप से overcommitted हैं, VM वास्तव में अनावश्यक रैम के साथ इतने अधिक संपर्क में हैं कि वास्तविक (छोटे) मेमोरी पदचिह्न क्लस्टर / होस्ट स्तर पर कोई स्मृति विवाद नहीं दिखाता है ...
मेरा उपाय यह है कि VMs वास्तव में ओएस-स्तरीय कैशिंग के लिए थोड़ा सा बफर के साथ सही आकार का होना चाहिए। अज्ञानता या विक्रेता "आवश्यकताओं" से बाहर निकलने के कारण यहां प्रस्तुत स्थिति पैदा होती है। मेमोरी बैलूनिंग हर मामले में खराब लगती है, क्योंकि इसमें परफॉर्मेंस इफेक्ट होता है, इसलिए राइट-सिजिंग से इसे रोकने में मदद मिल सकती है।
अपडेट 2: इनमें से कुछ वीएम दुर्घटनाग्रस्त होने लगे हैं:
kernel:BUG: soft lockup - CPU#1 stuck for 71s!
वीएमवेयर इसे भारी मेमोरी ओवरकोमिटमेंट के लक्षण के रूप में वर्णित करता है । इसलिए मुझे लगता है कि इस सवाल का जवाब है।
vCops "Oversized Virtual Machines" की रिपोर्ट ...
vCops "पुनर्प्राप्त करने योग्य अपशिष्ट" ग्राफ़ ...
