या लेखात आपण vSphere मधील रँडम ऍक्सेस मेमरी (RAM) परफॉर्मन्स काउंटरबद्दल बोलू.
असे दिसते की प्रोसेसरपेक्षा मेमरीसह सर्वकाही अधिक स्पष्ट आहे: व्हीएमवर कार्यप्रदर्शन समस्या उद्भवल्यास, त्या लक्षात न घेणे कठीण आहे. परंतु ते दिसल्यास, त्यांच्याशी सामना करणे अधिक कठीण आहे. पण प्रथम गोष्टी प्रथम.
सिद्धांताचा बिट
व्हर्च्युअल मशीनची RAM ज्या सर्व्हरवर VM चालू आहेत त्या सर्व्हरच्या मेमरीमधून घेतली जाते. हे अगदी स्पष्ट आहे :). सर्व्हरची RAM प्रत्येकासाठी पुरेशी नसल्यास, ESXi मेमरी सुधारण्याचे तंत्र वापरण्यास सुरुवात करते. अन्यथा, VM ऑपरेटिंग सिस्टम RAM ऍक्सेस त्रुटींसह क्रॅश होतील.
ESXi RAM लोडवर अवलंबून कोणती तंत्रे वापरायची ते ठरवते:
मेमरी स्थिती
सीमा
क्रिया
उच्च
400% मिनि:शुल्क
वरच्या मर्यादेपर्यंत पोहोचल्यानंतर, मोठी मेमरी पृष्ठे लहान पृष्ठांमध्ये विभागली जातात (TPS मानक मोडमध्ये चालते).
साफ करा
100% मिनि:शुल्क
मोठ्या मेमरी पृष्ठे लहान मध्ये विभाजित आहेत, TPS सक्ती आहे.
मऊ
64% मिनि:शुल्क
TPS + बलून
हार्ड
32% मिनि:शुल्क
TPS + कॉम्प्रेस + स्वॅप
कमी
16% मिनि:शुल्क
कॉम्प्रेस + स्वॅप + ब्लॉक
minFree ही हायपरवाइजर चालवण्यासाठी आवश्यक असलेली RAM आहे.
सर्वसमावेशक ESXi 4.1 पर्यंत, minFree हे डीफॉल्टनुसार निश्चित केले गेले होते - सर्व्हरच्या RAM च्या 6% (टक्केवारी ESXi वरील Mem.MinFreePct पर्यायाद्वारे बदलली जाऊ शकते). नंतरच्या आवृत्त्यांमध्ये, सर्व्हरवरील मेमरीच्या वाढीमुळे, minFree ची गणना होस्टच्या मेमरीच्या प्रमाणाच्या आधारे केली जाऊ लागली, आणि निश्चित टक्केवारी मूल्यानुसार नाही.
minFree मूल्य (डीफॉल्ट) खालीलप्रमाणे मोजले जाते:
minFree साठी राखीव मेमरीची टक्केवारी
मेमरी श्रेणी
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
उरलेली मेमरी
उदाहरणार्थ, 128 GB RAM असलेल्या सर्व्हरसाठी, MinFree मूल्य खालीलप्रमाणे असेल:
मिनफ्री = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
सर्व्हर आणि रॅमवर अवलंबून, वास्तविक मूल्य दोनशे एमबीने भिन्न असू शकते.
minFree साठी राखीव मेमरीची टक्केवारी
मेमरी श्रेणी
128 GB साठी मूल्य
6%
0-4 GB
245,76 MB
4%
4-12 GB
327,68 MB
2%
12-28 GB
327,68 MB
1%
उर्वरित मेमरी (100 GB)
1024 MB
सामान्यतः, उत्पादक स्टँडसाठी, केवळ उच्च स्थिती सामान्य मानली जाऊ शकते. चाचणी आणि विकास बेंचसाठी, क्लिअर/सॉफ्ट स्टेट स्वीकार्य असू शकतात. जर होस्टवरील RAM 64% MinFree पेक्षा कमी असेल, तर त्यावर चालू असलेल्या VM ला नक्कीच कार्यप्रदर्शन समस्या येत आहेत.
प्रत्येक राज्यात, काही मेमरी रिक्लेमेशन तंत्रे वापरली जातात, TPS पासून सुरुवात करून, ज्याचा VM कार्यक्षमतेवर अक्षरशः कोणताही परिणाम होत नाही, स्वॅपिंग पर्यंत. मी तुम्हाला त्यांच्याबद्दल अधिक सांगेन.
पारदर्शक पृष्ठ सामायिकरण (TPS). TPS म्हणजे, साधारणपणे, सर्व्हरवरील व्हर्च्युअल मशीनच्या RAM पृष्ठांचे डुप्लिकेशन.
ESXi पृष्ठांची हॅश बेरीज मोजून आणि तुलना करून समान आभासी मशीन RAM पृष्ठे शोधते आणि डुप्लिकेट पृष्ठे काढून टाकते, त्यांना सर्व्हरच्या भौतिक मेमरीमधील समान पृष्ठाच्या संदर्भांसह पुनर्स्थित करते. परिणामी, भौतिक मेमरी वापर कमी होतो आणि काही मेमरी ओव्हरसबस्क्रिप्शन अक्षरशः कोणत्याही कार्यप्रदर्शन प्रभावाशिवाय साध्य करता येते.
ही यंत्रणा केवळ 4 KB आकाराच्या मेमरी पृष्ठांसाठी कार्य करते (लहान पृष्ठे). हायपरवाइजर 2 MB आकाराची (मोठी पृष्ठे) पृष्ठे काढून टाकण्याचा प्रयत्न देखील करत नाही: या आकाराची एकसारखी पृष्ठे शोधण्याची शक्यता फारशी नाही.
डीफॉल्टनुसार, ESXi मोठ्या पानांना मेमरी वाटप करते. मोठ्या पृष्ठांचे लहान पृष्ठांमध्ये विभाजन करणे जेव्हा उच्च स्थितीचा उंबरठा गाठला जातो तेव्हा सुरू होतो आणि जेव्हा क्लिअर स्थिती गाठली जाते तेव्हा सक्ती केली जाते (हायपरवाइजर स्टेट टेबल पहा).
तुम्हाला टीपीएसने यजमान रॅम भरण्‍याची वाट न पाहता काम सुरू करण्याची इच्छा असल्यास, तुम्हाला प्रगत पर्याय ESXi मध्ये मूल्य सेट करणे आवश्यक आहे. “Mem.AllocGuestLargePage” ते 0 (डिफॉल्ट 1). नंतर व्हर्च्युअल मशीनसाठी मोठ्या मेमरी पृष्ठांचे वाटप अक्षम केले जाईल.
डिसेंबर 2014 पासून, सर्व ESXi रिलीझमध्ये, VM दरम्यान TPS डिफॉल्टनुसार अक्षम केले आहे, कारण एक भेद्यता आढळून आली की सैद्धांतिकदृष्ट्या एका VM ला दुसर्‍या VM च्या RAM मध्ये प्रवेश करण्याची परवानगी देते. तपशील येथे. TPS असुरक्षिततेचे शोषण करण्याच्या व्यावहारिक अंमलबजावणीबद्दल मला माहिती मिळाली नाही.
TPS धोरण प्रगत पर्यायाद्वारे नियंत्रित केले जाते "Mem.ShareForceSalting" ESXi वर:
0 - इंटर-व्हीएम टीपीएस. TPS वेगवेगळ्या VM च्या पृष्ठांसाठी कार्य करते;
1 – VMX मध्ये समान “sched.mem.pshare.salt” मूल्य असलेल्या VM साठी TPS;
2 (डीफॉल्ट) – इंट्रा-व्हीएम TPS. TPS VM मधील पृष्ठांसाठी कार्य करते.
मोठी पृष्ठे अक्षम करणे आणि चाचणी बेंचवर इंटर-व्हीएम टीपीएस सक्षम करणे निश्चितपणे अर्थपूर्ण आहे. हे मोठ्या संख्येने समान VM असलेल्या स्टँडसाठी देखील वापरले जाऊ शकते. उदाहरणार्थ, VDI सह स्टँडवर, भौतिक मेमरीमधील बचत दहापट टक्क्यांपर्यंत पोहोचू शकते.
मेमरी बलूनिंग. VM ऑपरेटिंग सिस्टमसाठी बलूनिंग हे आता TPS सारखे निरुपद्रवी आणि पारदर्शक तंत्र राहिलेले नाही. परंतु योग्यरित्या वापरल्यास, आपण बलूनिंगसह जगू शकता आणि कार्य देखील करू शकता.
व्हीएमवेअर टूल्ससह, बलून ड्रायव्हर (उर्फ vmmemctl) नावाचा एक विशेष ड्राइव्हर VM वर स्थापित केला आहे. जेव्हा हायपरवाइजरची भौतिक मेमरी संपुष्टात येऊ लागते आणि सॉफ्ट स्टेटमध्ये प्रवेश करतो, तेव्हा ESXi VM ला या बलून ड्रायव्हरद्वारे न वापरलेली RAM परत मिळवण्यास सांगते. ड्रायव्हर, यामधून, ऑपरेटिंग सिस्टम स्तरावर कार्य करतो आणि त्यातून विनामूल्य मेमरीची विनंती करतो. हायपरवाइजर पाहतो की बलून ड्रायव्हरने भौतिक मेमरीची कोणती पृष्ठे व्यापली आहेत, व्हर्च्युअल मशीनमधून मेमरी घेते आणि होस्टला परत करते. ओएसच्या ऑपरेशनमध्ये कोणतीही समस्या नाही, कारण ओएस स्तरावर मेमरी बलून ड्रायव्हरने व्यापलेली आहे. डीफॉल्टनुसार, बलून ड्रायव्हर 65% पर्यंत VM मेमरी घेऊ शकतो.
व्हीएमवर व्हीएमवेअर टूल्स इन्स्टॉल केलेले नसल्यास किंवा बलूनिंग अक्षम केले असल्यास (मी याची शिफारस करत नाही, परंतु तेथे आहे :), हायपरवाइजर ताबडतोब मेमरी काढून टाकण्यासाठी अधिक कठोर तंत्रांवर स्विच करतो. निष्कर्ष: VMware टूल्स VM वर असल्याची खात्री करा.
बलून ड्रायव्हरचे ऑपरेशन OS वरून VMware Tools द्वारे तपासले जाऊ शकते.
मेमरी कॉम्प्रेशन. जेव्हा ESXi हार्ड स्थितीत पोहोचते तेव्हा हे तंत्र वापरले जाते. नावाप्रमाणेच, ESXi RAM चे 4KB पृष्ठ 2KB मध्ये संकुचित करण्याचा प्रयत्न करते, ज्यामुळे सर्व्हरच्या भौतिक मेमरीमध्ये काही जागा मोकळी होते. हे तंत्र VM RAM पृष्ठांच्या सामग्रीसाठी प्रवेश वेळ लक्षणीयरीत्या वाढवते, कारण पृष्ठ प्रथम डीकंप्रेस करणे आवश्यक आहे. कधीकधी सर्व पृष्ठे संकुचित केली जाऊ शकत नाहीत आणि प्रक्रियेस थोडा वेळ लागतो. म्हणून, हे तंत्र सराव मध्ये फार प्रभावी नाही.
मेमरी स्वॅपिंग. मेमरी कॉम्प्रेशनच्या छोट्या टप्प्यानंतर, ESXi जवळजवळ अपरिहार्यपणे (जर VMs इतर होस्टवर हलवले नाहीत किंवा बंद केले नाहीत तर) स्वॅपिंगवर स्विच करते. आणि जर खूप कमी मेमरी शिल्लक असेल (कमी स्थिती), तर हायपरवाइजर व्हीएमला मेमरी पृष्ठे वाटप करणे देखील थांबवते, ज्यामुळे व्हीएमच्या अतिथी ओएसमध्ये समस्या उद्भवू शकतात.
अशा प्रकारे स्वॅपिंग कार्य करते. जेव्हा तुम्ही व्हर्च्युअल मशीन चालू करता, तेव्हा त्यासाठी .vswp एक्स्टेंशन असलेली फाइल तयार केली जाते. हे VM च्या अनारक्षित RAM च्या आकारात समान आहे: कॉन्फिगर केलेल्या आणि आरक्षित मेमरीमध्ये हा फरक आहे. स्वॅपिंग चालू असताना, ESXi या फाइलमध्ये व्हर्च्युअल मशीन मेमरी पृष्ठे स्वॅप करते आणि सर्व्हरच्या भौतिक मेमरीच्या ऐवजी त्याच्यासह कार्य करण्यास प्रारंभ करते. अर्थात, अशी “RAM” मेमरी ही .vswp जलद स्टोरेजवर असली तरीही, रिअल मेमरी पेक्षा कमी प्रमाणात असते.
बलूनिंगच्या विपरीत, जेव्हा न वापरलेली पृष्ठे VM मधून घेतली जातात, तेव्हा OS द्वारे सक्रियपणे वापरलेली पृष्ठे किंवा VM मधील अनुप्रयोगांना स्वॅपिंगसह डिस्कवर हलवता येते. परिणामी, व्हीएमची कार्यक्षमता गोठण्याच्या टप्प्यापर्यंत खाली येते. VM औपचारिकपणे काम करत आहे आणि कमीतकमी ते OS वरून योग्यरित्या अक्षम केले जाऊ शकते. जर तुम्ही धीर धरत असाल तर 😉
जर VM स्वॅपमध्ये गेले असतील, तर ही आणीबाणीची परिस्थिती आहे जी शक्य असल्यास टाळता येईल.
मूलभूत आभासी मशीन मेमरी कामगिरी काउंटर
तर आम्ही मुख्य गोष्टीकडे आलो. VM च्या मेमरी स्थितीचे परीक्षण करण्यासाठी, खालील काउंटर आहेत:
सक्रिय — मागील मापन कालावधीमध्ये VM ने प्रवेश केलेल्या RAM (KB) चे प्रमाण दर्शविते.
वापर — सक्रिय प्रमाणेच, परंतु VM च्या कॉन्फिगर केलेल्या RAM च्या टक्केवारीनुसार. खालील सूत्र वापरून गणना केली: सक्रिय ÷ आभासी मशीन कॉन्फिगर केलेली मेमरी आकार.
उच्च वापर आणि सक्रिय, अनुक्रमे, नेहमी VM कार्यप्रदर्शन समस्यांचे सूचक नसतात. जर VM आक्रमकपणे मेमरी वापरत असेल (किमान त्यात प्रवेश करत असेल), तर याचा अर्थ पुरेशी मेमरी नाही असा होत नाही. उलट, OS मध्ये काय चालले आहे ते पाहण्याचे हे एक कारण आहे.
VM साठी मेमरी वापरासाठी मानक अलार्म आहे:
शेअर — TPS वापरून डुप्लिकेट केलेल्या VM RAM चे प्रमाण (VM मध्ये किंवा VMs दरम्यान).
मंजूर — होस्ट फिजिकल मेमरी (KB) ची रक्कम जी VM ला वाटप करण्यात आली होती. सामायिक सक्षम करते.
सेवन केले (मंजूर - शेअर केलेले) - VM होस्टकडून वापरत असलेली भौतिक मेमरी (KB). सामायिक समाविष्ट नाही.
जर VM मेमरीचा काही भाग होस्टच्या भौतिक मेमरीमधून दिला गेला नाही तर स्वॅप फाइलमधून दिला गेला असेल किंवा मेमरी VM मधून बलून ड्रायव्हरद्वारे घेतली गेली असेल, तर ही रक्कम ग्रँटेड आणि कन्झ्युम्डमध्ये विचारात घेतली जात नाही.
उच्च मंजूर आणि उपभोग मूल्ये पूर्णपणे सामान्य आहेत. ऑपरेटिंग सिस्टम हळूहळू हायपरवाइजरकडून मेमरी घेते आणि ती परत देत नाही. कालांतराने, सक्रियपणे चालू असलेल्या व्हीएममध्ये, या काउंटरची मूल्ये कॉन्फिगर केलेल्या मेमरीच्या प्रमाणात पोहोचतात आणि तिथेच राहतात.
शून्य — VM RAM (KB) चे प्रमाण, ज्यामध्ये शून्य असतात. अशी मेमरी हायपरवाइजरद्वारे विनामूल्य मानली जाते आणि इतर आभासी मशीन्सना दिली जाऊ शकते. अतिथी OS ने शून्य केलेल्या मेमरीवर काहीतरी लिहिल्यानंतर, ते Consumed मध्ये जाते आणि परत येत नाही.
आरक्षित ओव्हरहेड — VM RAM चे प्रमाण, (KB) VM ऑपरेशनसाठी हायपरवाइजरने आरक्षित केले आहे. ही एक लहान रक्कम आहे, परंतु ती होस्टवर उपलब्ध असणे आवश्यक आहे, अन्यथा VM सुरू होणार नाही.
फुगा — बलून ड्रायव्हर वापरून VM मधून काढलेली RAM (KB) रक्कम.
संकुचित — संकुचित केलेली RAM (KB) चे प्रमाण.
अदलाबदल — RAM (KB) चे प्रमाण, जे, सर्व्हरवरील भौतिक मेमरीच्या कमतरतेमुळे, डिस्कवर हलविले.
बलून आणि इतर मेमरी रिक्लेमेशन तंत्र काउंटर शून्य आहेत.
150 GB RAM सह साधारणपणे कार्यरत VM च्या मेमरी काउंटरसह आलेख असा दिसतो.
खालील आलेखामध्ये, VM मध्ये स्पष्ट समस्या आहेत. आलेखाच्या खाली आपण पाहू शकता की या VM साठी RAM सह कार्य करण्यासाठी सर्व वर्णित तंत्रे वापरली गेली होती. या VM साठी बलून Consumed पेक्षा खूप मोठा आहे. खरं तर, व्हीएम जिवंत पेक्षा अधिक मृत आहे.
ESXTOP
CPU प्रमाणेच, जर आम्हाला होस्टवरील परिस्थितीचे तसेच 2 सेकंदांच्या अंतराने त्याच्या गतिशीलतेचे त्वरीत मूल्यांकन करायचे असेल, तर आम्ही ESXTOP चा वापर केला पाहिजे.
ESXTOP मेमरी स्क्रीनला “m” की सह कॉल केले जाते आणि ते असे दिसते (फील्ड B,D,H,J,K,L,O निवडले):
खालील पॅरामीटर्स आमच्यासाठी स्वारस्यपूर्ण असतील:
मेम ओव्हरकमिट सरासरी — होस्टवर 1, 5 आणि 15 मिनिटांसाठी मेमरी ओव्हरसबस्क्रिप्शनचे सरासरी मूल्य. जर ते शून्याच्या वर असेल, तर काय घडत आहे ते पाहण्याचे हे एक कारण आहे, परंतु नेहमीच समस्यांचे सूचक नाही.
ओळींमध्ये PMEM/MB и VMKMEM/MB — सर्व्हरची भौतिक मेमरी आणि VMkernel वर उपलब्ध असलेल्या मेमरीबद्दल माहिती. येथे मनोरंजक गोष्टींपैकी आपण minfree मूल्य (MB मध्ये), मेमरीमधील होस्ट स्थिती (आमच्या बाबतीत, उच्च) पाहू शकता.
ओळीत NUMA/MB तुम्ही NUMA नोड्स (सॉकेट्स) वर RAM चे वितरण पाहू शकता. या उदाहरणात, वितरण असमान आहे, जे तत्त्वतः फार चांगले नाही.
मेमरी रिक्लेमेशन तंत्रासाठी खालील सामान्य सर्व्हर आकडेवारी आहे:
PSHARE/MB — ही TPS आकडेवारी आहेत;
स्वॅप/एमबी - स्वॅप वापर आकडेवारी;
झिप/एमबी - मेमरी पृष्ठ कॉम्प्रेशन आकडेवारी;
MEMCTL/MB - बलून ड्रायव्हर वापर आकडेवारी.
वैयक्तिक VM साठी, आम्हाला खालील माहितीमध्ये स्वारस्य असू शकते. प्रेक्षकांना गोंधळात टाकू नये म्हणून मी VM ची नावे लपवली :). ESXTOP मेट्रिक vSphere मधील काउंटर सारखे असल्यास, मी संबंधित काउंटर प्रदान करेन.
MEMSZ — VM (MB) वर कॉन्फिगर केलेल्या मेमरीचे प्रमाण.
MEMSZ = GRANT + MCTLSZ + SWCUR + अनटच.
अनुदान — MB मध्ये मंजूर.
TCHD — MByte मध्ये सक्रिय.
एमसीटीएल? — VM वर बलून ड्रायव्हर स्थापित केले आहे की नाही.
MCTLSZ - बलून ते एमबी.
MCTLGT — ESXi ला VM मधून बलून ड्रायव्हर (Memctl टार्गेट) द्वारे काढू इच्छित असलेली RAM (MBytes) चे प्रमाण.
MCTLMAX — बलून ड्रायव्हरद्वारे ESXi VM मधून जास्तीत जास्त RAM (MBytes) काढू शकते.
SWCUR — स्वॅप फाइलमधून VM ला वाटप केलेली RAM (MBytes) ची सध्याची रक्कम.
S.W.G.T. — ESXi ला स्वॅप फाइल (स्वॅप टार्गेट) मधून VM ला देऊ इच्छित असलेली RAM (MBytes) ची रक्कम.
तुम्ही ESXTOP द्वारे VM च्या NUMA टोपोलॉजीबद्दल अधिक तपशीलवार माहिती देखील पाहू शकता. हे करण्यासाठी, D, G फील्ड निवडा:
एनएचएन – NUMA नोड्स ज्यावर VM स्थित आहे. येथे तुम्हाला वाइड vm लगेच लक्षात येईल, जे एका NUMA नोडवर बसत नाही.
NRMEM - रिमोट NUMA नोडमधून VM किती मेगाबाइट मेमरी घेते.
NLMEM - स्थानिक NUMA नोडमधून VM किती मेगाबाइट मेमरी घेते.
N%L - स्थानिक NUMA नोडवर VM मेमरीची टक्केवारी (जर 80% पेक्षा कमी असेल, कार्यप्रदर्शन समस्या उद्भवू शकतात).
हायपरवाइजरवर मेमरी
जर हायपरवाइजरसाठी सीपीयू काउंटर सहसा विशेष स्वारस्य नसतील, तर मेमरीसह परिस्थिती उलट आहे. VM वरील उच्च मेमरी वापर नेहमीच कार्यप्रदर्शन समस्या दर्शवत नाही, परंतु हायपरवाइजरवरील उच्च मेमरी वापरामुळे मेमरी व्यवस्थापन तंत्र सुरू होते आणि VM कार्यक्षमतेमध्ये समस्या निर्माण होतात. तुम्हाला होस्ट मेमरी वापर अलार्मचे निरीक्षण करणे आणि VM ला स्वॅपमध्ये येण्यापासून प्रतिबंधित करणे आवश्यक आहे.
अदलाबदल करा
जर व्हीएम स्वॅपमध्ये पकडला गेला तर त्याची कार्यक्षमता मोठ्या प्रमाणात कमी होते. होस्टवर फ्री रॅम दिसल्यानंतर बलूनिंग आणि कॉम्प्रेशनचे ट्रेस त्वरीत अदृश्य होतात, परंतु व्हर्च्युअल मशीनला स्वॅपमधून सर्व्हरच्या रॅमवर परत येण्याची घाई नाही.
ESXi 6.0 पूर्वी, स्वॅपमधून VM काढण्याचा एकमेव विश्वासार्ह आणि जलद मार्ग म्हणजे रीबूट करणे (अधिक तंतोतंत, कंटेनर बंद/चालू करा). ESXi 6.0 सह प्रारंभ करून, पूर्णपणे अधिकृत नसले तरी, स्वॅपमधून VM काढण्याचा एक कार्यरत आणि विश्वासार्ह मार्ग दिसून आला आहे. एका परिषदेत, मी CPU शेड्युलरसाठी जबाबदार असलेल्या VMware अभियंत्यांपैकी एकाशी बोलू शकलो. त्यांनी पुष्टी केली की ही पद्धत खूपच कार्यरत आणि सुरक्षित आहे. आमच्या अनुभवानुसार, त्यात कोणतीही समस्या नव्हती.
स्वॅपमधून VM काढण्यासाठी वास्तविक आदेश डंकन एपिंग. मी तपशीलवार वर्णनाची पुनरावृत्ती करणार नाही, मी फक्त त्याच्या वापराचे उदाहरण देईन. जसे आपण स्क्रीनशॉटमध्ये पाहू शकता, निर्दिष्ट कमांड कार्यान्वित केल्यानंतर काही वेळाने, VM वर स्वॅप अदृश्य होते.
ESXi वर RAM व्यवस्थापित करण्यासाठी टिपा
शेवटी, येथे काही टिपा आहेत ज्या तुम्हाला RAM मुळे VM कार्यप्रदर्शनातील समस्या टाळण्यास मदत करतील:
- उत्पादक क्लस्टर्समध्ये RAM चे ओव्हरसबस्क्रिप्शन टाळा. क्लस्टरमध्ये नेहमी ~20-30% विनामूल्य मेमरी असणे उचित आहे जेणेकरून DRS (आणि प्रशासक) कडे युक्ती चालवायला जागा असेल आणि स्थलांतर करताना VM स्वॅपमध्ये जाऊ नयेत. तसेच, दोष सहिष्णुतेसाठी मार्जिनबद्दल विसरू नका. जेव्हा एखादा सर्व्हर अयशस्वी होतो आणि HA वापरून VM रीबूट होतो, तेव्हा काही मशीन स्वॅपमध्ये जातात तेव्हा हे अप्रिय असते.
- अत्यंत एकत्रित केलेल्या पायाभूत सुविधांमध्ये, होस्ट मेमरीच्या अर्ध्यापेक्षा जास्त मेमरीसह VM तयार करण्याचा प्रयत्न करू नका. हे पुन्हा डीआरएसला क्लस्टर सर्व्हरवर व्हर्च्युअल मशीन वितरीत करण्यात मदत करेल. हा नियम अर्थातच सार्वत्रिक नाही :).
- होस्ट मेमरी वापर अलार्मकडे लक्ष द्या.
- VM वर VMware Tools इंस्टॉल करायला विसरू नका आणि Ballooning बंद करू नका.
- इंटर-व्हीएम टीपीएस सक्षम करण्याचा आणि व्हीडीआय आणि चाचणी वातावरणात मोठी पृष्ठे अक्षम करण्याचा विचार करा.
- VM ला कार्यप्रदर्शन समस्या येत असल्यास, ते रिमोट NUMA नोडवरून मेमरी वापरत आहे का ते तपासा.
- शक्य तितक्या लवकर स्वॅपमधून VM काढा! इतर गोष्टींबरोबरच, VM स्वॅपमध्ये असल्यास, स्टोरेज सिस्टमला स्पष्ट कारणांमुळे त्रास होतो.
माझ्यासाठी रॅमबद्दल एवढेच आहे. ज्यांना खोलवर जायचे आहे त्यांच्यासाठी खाली संबंधित लेख आहेत. पुढील लेख स्टोरेजला समर्पित असेल.
उपयुक्त दुवे
स्त्रोत: www.habr.com