VMware vSphere માં VM પ્રદર્શન વિશ્લેષણ. ભાગ 2: મેમરી

ભાગ 1. CPU વિશે

આ લેખમાં, આપણે vSphere માં રેન્ડમ એક્સેસ મેમરી (RAM) ના પરફોર્મન્સ કાઉન્ટર્સ વિશે વાત કરીશું.
એવું લાગે છે કે મેમરી સાથે બધું પ્રોસેસર કરતાં વધુ સ્પષ્ટ છે: જો VM માં કામગીરીની સમસ્યાઓ હોય, તો તેને ધ્યાનમાં લેવું મુશ્કેલ છે. પરંતુ જો તેઓ દેખાય છે, તો તેમની સાથે વ્યવહાર કરવો વધુ મુશ્કેલ છે. પરંતુ પ્રથમ વસ્તુઓ પ્રથમ.

સિદ્ધાંત એક બીટ

વર્ચ્યુઅલ મશીનોની RAM એ સર્વરની મેમરીમાંથી લેવામાં આવે છે જેના પર VM ચાલી રહ્યા છે. તે એકદમ સ્પષ્ટ છે :). જો સર્વરની RAM દરેક માટે પૂરતી નથી, તો ESXi RAM ના વપરાશને ઑપ્ટિમાઇઝ કરવા માટે મેમરી રીક્લેમેશન તકનીકોનો ઉપયોગ કરવાનું શરૂ કરે છે. નહિંતર, 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 (ડિફૉલ્ટ) મૂલ્ય નીચે પ્રમાણે ગણવામાં આવે છે:

મિનિટ ફ્રી માટે અનામત મેમરીની ટકાવારી

મેમરી શ્રેણી

6%

0-4 જીબી

4%

4-12 જીબી

2%

12-28 જીબી

1%

બાકી મેમરી

સોર્સ

ઉદાહરણ તરીકે, 128 GB RAM ધરાવતા સર્વર માટે, MinFree મૂલ્ય હશે:
મિનફ્રી = 245,76 + 327,68 + 327,68 + 1024 = 1925,12MB = 1,88GB
વાસ્તવિક મૂલ્ય સો એમબીના દંપતિથી અલગ હોઈ શકે છે, તે સર્વર અને રેમ પર આધારિત છે.

મિનિટ ફ્રી માટે અનામત મેમરીની ટકાવારી

મેમરી શ્રેણી

128 GB માટે મૂલ્ય

6%

0-4 જીબી

245,76 એમબી

4%

4-12 જીબી

327,68 એમબી

2%

12-28 જીબી

327,68 એમબી

1%

બાકી મેમરી (100 GB)

1024 એમબી

સામાન્ય રીતે, ઉત્પાદક સ્ટેન્ડ માટે, માત્ર ઉચ્ચ સ્થિતિને સામાન્ય ગણી શકાય. ટેસ્ટ અને ડેવલપમેન્ટ બેન્ચ માટે, ક્લિયર/સોફ્ટ સ્ટેટ્સ સ્વીકાર્ય હોઈ શકે છે. જો હોસ્ટ પરની RAM 64% MinFree કરતાં ઓછી હોય, તો તેના પર ચાલતા VM ને ચોક્કસપણે કામગીરીની સમસ્યા હોય છે.

દરેક રાજ્યમાં, અમુક મેમરી પુનઃપ્રાપ્તિ તકનીકો લાગુ કરવામાં આવે છે, જે TPS થી શરૂ થાય છે, જે વ્યવહારીક રીતે VM ના પ્રભાવને અસર કરતી નથી, અને સ્વેપિંગ સાથે સમાપ્ત થાય છે. હું તમને તેમના વિશે વધુ કહીશ.

પારદર્શક પૃષ્ઠ શેરિંગ (TPS). TPS, લગભગ કહીએ તો, સર્વર પર વર્ચ્યુઅલ મશીન મેમરી પેજનું ડિડુપ્લિકેશન છે.

ESXi પૃષ્ઠોના હેશ સરવાળાની ગણતરી અને સરખામણી કરીને વર્ચ્યુઅલ મશીન RAM ના સમાન પૃષ્ઠો શોધે છે, અને ડુપ્લિકેટ પૃષ્ઠોને દૂર કરે છે, તેમને સર્વરની ભૌતિક મેમરીમાં સમાન પૃષ્ઠની લિંક્સ સાથે બદલીને. પરિણામે, ભૌતિક મેમરીનો વપરાશ ઓછો થાય છે અને કેટલીક મેમરી ઓવરસબ્સ્ક્રિપ્શન ઓછી અથવા કોઈ કામગીરીમાં ઘટાડો સાથે પ્રાપ્ત કરી શકાય છે.

સોર્સ

આ મિકેનિઝમ માત્ર 4 KB મેમરી પેજ (નાના પેજ) માટે કામ કરે છે. હાઇપરવાઇઝર 2 MB (મોટા પૃષ્ઠો) ના પૃષ્ઠોને અનુમાનિત કરવાનો પ્રયાસ પણ કરતું નથી: આ કદના સમાન પૃષ્ઠો શોધવાની તક મહાન નથી.

મૂળભૂત રીતે, ESXi મોટા પૃષ્ઠોને મેમરી ફાળવે છે. મોટા પૃષ્ઠોને નાના પૃષ્ઠોમાં તોડવાનું શરૂ થાય છે જ્યારે ઉચ્ચ સ્થિતિ થ્રેશોલ્ડ પહોંચી જાય છે અને જ્યારે ક્લિયર સ્ટેટ પર પહોંચી જાય ત્યારે ફરજ પાડવામાં આવે છે (હાયપરવાઇઝર સ્ટેટ ટેબલ જુઓ).

જો તમે ઇચ્છો છો કે TPS હોસ્ટ રેમ ભરવાની રાહ જોયા વિના કામ કરવાનું શરૂ કરે, તો એડવાન્સ્ડ ઓપ્શન્સ ESXi માં તમારે મૂલ્ય સેટ કરવાની જરૂર છે. “Mem.AllocGuestLargePage” થી 0 (ડિફોલ્ટ 1). પછી વર્ચ્યુઅલ મશીનો માટે મોટા મેમરી પૃષ્ઠોની ફાળવણી અક્ષમ થઈ જશે.

ડિસેમ્બર 2014 થી, ESXi ના તમામ પ્રકાશનોમાં, VM વચ્ચે TPS ડિફૉલ્ટ રૂપે અક્ષમ કરવામાં આવ્યું છે, કારણ કે નબળાઈ જોવા મળી હતી કે સૈદ્ધાંતિક રીતે એક VM થી બીજા VMની RAM સુધી ઍક્સેસ કરવાની મંજૂરી આપે છે. વિગતો અહીં. TPS નબળાઈનો ઉપયોગ કરવાના વ્યવહારિક અમલીકરણ વિશે મને માહિતી મળી નથી.

TPS નીતિ અદ્યતન વિકલ્પ દ્વારા નિયંત્રિત "Mem.ShareForceSalting" ESXi પર:
0 - ઇન્ટર-વીએમ TPS. TPS વિવિધ VM ના પૃષ્ઠો માટે કાર્ય કરે છે;
1 – VMX માં સમાન “sched.mem.pshare.salt” મૂલ્ય સાથે VM માટે TPS;
2 (ડિફોલ્ટ) - ઇન્ટ્રા-વીએમ TPS. TPS VM ની અંદરના પૃષ્ઠો માટે કામ કરે છે.

તે ચોક્કસપણે અર્થપૂર્ણ છે કે મોટા પૃષ્ઠોને બંધ કરો અને પરીક્ષણ બેન્ચ પર ઇન્ટર-વીએમ TPS ચાલુ કરો. તેનો ઉપયોગ મોટી સંખ્યામાં સમાન પ્રકારના VM સાથે સ્ટેન્ડ માટે પણ થઈ શકે છે. ઉદાહરણ તરીકે, VDI સાથે સ્ટેન્ડ પર, ભૌતિક મેમરીમાં બચત દસ ટકા સુધી પહોંચી શકે છે.

મેમરી બલૂનિંગ. VM ઓપરેટિંગ સિસ્ટમ માટે TPS જેવી હાનિકારક અને પારદર્શક તકનીક હવે બલૂનિંગ રહી નથી. પરંતુ યોગ્ય એપ્લિકેશન સાથે, તમે બલૂનિંગ સાથે જીવી શકો છો અને કામ પણ કરી શકો છો.

Vmware ટૂલ્સ સાથે મળીને, VM પર બલૂન ડ્રાઈવર (ઉર્ફે vmmemctl) નામનો વિશેષ ડ્રાઈવર સ્થાપિત થયેલ છે. જ્યારે હાઇપરવાઇઝર ભૌતિક મેમરી સમાપ્ત થવાનું શરૂ કરે છે અને સોફ્ટ સ્થિતિમાં પ્રવેશે છે, ત્યારે ESXi VMને આ બલૂન ડ્રાઇવર દ્વારા ન વપરાયેલ રેમનો ફરીથી દાવો કરવા કહે છે. ડ્રાઇવર, બદલામાં, ઓપરેટિંગ સિસ્ટમ સ્તર પર કામ કરે છે અને તેમાંથી મફત મેમરીની વિનંતી કરે છે. હાઇપરવાઇઝર જુએ છે કે બલૂન ડ્રાઇવરે ભૌતિક મેમરીના કયા પૃષ્ઠો કબજે કર્યા છે, વર્ચ્યુઅલ મશીનમાંથી મેમરી લે છે અને તેને હોસ્ટને પરત કરે છે. OS ના ઑપરેશનમાં કોઈ સમસ્યા નથી, કારણ કે OS સ્તર પર મેમરી બલૂન ડ્રાઇવર દ્વારા કબજે કરવામાં આવે છે. મૂળભૂત રીતે બલૂન ડ્રાઈવર VM મેમરીના 65% સુધી લઈ શકે છે.

જો VMવેર ટૂલ્સ VM પર ઇન્સ્ટોલ કરેલ નથી અથવા બલૂનિંગ અક્ષમ છે (હું ભલામણ કરતો નથી, પરંતુ ત્યાં છે KB:), હાઇપરવાઇઝર તરત જ વધુ કડક મેમરી દૂર કરવાની તકનીકો પર સ્વિચ કરે છે. નિષ્કર્ષ: ખાતરી કરો કે VMware સાધનો VM પર છે.

VMware ટૂલ્સ દ્વારા OS માંથી બલૂન ડ્રાઇવરની કામગીરી તપાસી શકાય છે.

મેમરી કમ્પ્રેશન. જ્યારે ESXi સખત સ્થિતિમાં પહોંચે છે ત્યારે આ તકનીકનો ઉપયોગ કરવામાં આવે છે. નામ પ્રમાણે, ESXi RAM ના 4KB પૃષ્ઠને 2KB માં સંકોચવાનો પ્રયાસ કરે છે અને આમ સર્વરની ભૌતિક મેમરી પર થોડી જગ્યા ખાલી કરે છે. આ ટેકનીક VM RAM પૃષ્ઠોના સમાવિષ્ટો સુધી પહોંચવાના સમયને નોંધપાત્ર રીતે વધારે છે, કારણ કે પૃષ્ઠ પ્રથમ અસંકુચિત હોવું જોઈએ. કેટલીકવાર બધા પૃષ્ઠોને સંકુચિત કરી શકાતા નથી અને પ્રક્રિયામાં થોડો સમય લાગે છે. તેથી, આ તકનીક વ્યવહારમાં ખૂબ અસરકારક નથી.

મેમરી સ્વેપિંગ. ટૂંકા મેમરી કમ્પ્રેશન તબક્કા પછી, ESXi લગભગ અનિવાર્યપણે (જો VM અન્ય યજમાનો માટે છોડ્યું ન હોય અથવા બંધ ન કર્યું હોય) સ્વેપિંગ પર સ્વિચ કરશે. અને જો ત્યાં બહુ ઓછી મેમરી બાકી હોય (નીચી સ્થિતિ), તો હાઇપરવાઇઝર VM ને મેમરી પેજીસ ફાળવવાનું પણ બંધ કરે છે, જે VM ના ગેસ્ટ OS માં સમસ્યા ઊભી કરી શકે છે.

અદલાબદલી કેવી રીતે કાર્ય કરે છે તે અહીં છે. જ્યારે તમે વર્ચ્યુઅલ મશીન ચાલુ કરો છો, ત્યારે તેના માટે .vswp એક્સ્ટેંશનવાળી ફાઇલ બનાવવામાં આવે છે. તે VM ની અનરિઝર્વ્ડ RAM ના કદમાં સમાન છે: તે રૂપરેખાંકિત અને આરક્ષિત મેમરી વચ્ચેનો તફાવત છે. જ્યારે સ્વેપિંગ ચાલી રહ્યું હોય, ત્યારે ESXi વર્ચ્યુઅલ મશીન મેમરી પેજીસને આ ફાઇલમાં અનલોડ કરે છે અને સર્વરની ભૌતિક મેમરીને બદલે તેની સાથે કામ કરવાનું શરૂ કરે છે. અલબત્ત, આવી "ઓપરેટિવ" મેમરી વાસ્તવિક કરતાં ઘણી ધીમી તીવ્રતાની હોય છે, ભલે .vswp ઝડપી સ્ટોરેજ પર હોય.

બલૂનિંગથી વિપરીત, જ્યારે બિનઉપયોગી પૃષ્ઠો VM માંથી લેવામાં આવે છે, સ્વેપિંગ સાથે, પૃષ્ઠો કે જે OS દ્વારા સક્રિય રીતે ઉપયોગમાં લેવાય છે અથવા VM ની અંદરની એપ્લિકેશનો ડિસ્ક પર જઈ શકે છે. પરિણામે, VM નું પ્રદર્શન ઠંડું થવાના બિંદુ સુધી નીચે આવે છે. VM ઔપચારિક રીતે કામ કરે છે અને ઓછામાં ઓછું તેને OS માંથી યોગ્ય રીતે અક્ષમ કરી શકાય છે. જો તમે ધીરજ રાખો છો 😉

જો VMs સ્વેપમાં ગયા હોય, તો આ એક અસાધારણ પરિસ્થિતિ છે, જે શક્ય હોય તો ટાળી શકાય છે.

કી VM મેમરી પ્રદર્શન કાઉન્ટર્સ

તેથી અમે મુખ્ય મુદ્દા પર પહોંચ્યા. VM માં મેમરીની સ્થિતિનું નિરીક્ષણ કરવા માટે, નીચેના કાઉન્ટર્સ છે:

સક્રિય — RAM (KB) ની માત્રા દર્શાવે છે કે જે VM ને અગાઉના માપન સમયગાળામાં ઍક્સેસ મળી હતી.

વપરાશ - સક્રિય જેવું જ છે, પરંતુ VM ની રૂપરેખાંકિત RAM ની ટકાવારી તરીકે. નીચેના સૂત્રનો ઉપયોગ કરીને ગણતરી કરવામાં આવે છે: સક્રિય ÷ વર્ચ્યુઅલ મશીન રૂપરેખાંકિત મેમરી કદ.
ઉચ્ચ વપરાશ અને સક્રિય, અનુક્રમે, હંમેશા VM પ્રદર્શન સમસ્યાઓના સૂચક નથી. જો VM આક્રમક રીતે મેમરીનો ઉપયોગ કરે છે (ઓછામાં ઓછું તેની ઍક્સેસ મેળવે છે), તો તેનો અર્થ એ નથી કે ત્યાં પૂરતી મેમરી નથી. તેના બદલે, OS માં શું થઈ રહ્યું છે તે જોવાનો પ્રસંગ છે.
VM માટે પ્રમાણભૂત મેમરી વપરાશ એલાર્મ છે:

વહેંચાયેલ - TPS (VM ની અંદર અથવા VM ની વચ્ચે) નો ઉપયોગ કરીને ડુપ્લિકેટ કરેલ VM RAM નો જથ્થો.

મંજૂર - ભૌતિક હોસ્ટ મેમરી (KB) ની માત્રા જે VM ને આપવામાં આવી હતી. વહેંચાયેલ સમાવેશ થાય છે.

વપરાશ (મંજૂર - વહેંચાયેલ) - ભૌતિક મેમરી (KB) ની માત્રા જે VM હોસ્ટ પાસેથી વાપરે છે. શેર કરેલ શામેલ નથી.

જો VM મેમરીનો ભાગ હોસ્ટની ભૌતિક મેમરીમાંથી નહીં, પરંતુ સ્વેપ ફાઇલમાંથી આપવામાં આવ્યો હોય, અથવા મેમરી VMમાંથી બલૂન ડ્રાઇવર દ્વારા લેવામાં આવી હોય, તો આ રકમ ગ્રાન્ટેડ અને કન્ઝ્યુમ્ડમાં ધ્યાનમાં લેવામાં આવતી નથી.
ઉચ્ચ ગ્રાન્ટેડ અને કન્ઝ્યુમ્ડ મૂલ્યો સંપૂર્ણપણે સામાન્ય છે. ઓપરેટિંગ સિસ્ટમ ધીમે ધીમે હાઇપરવાઇઝર પાસેથી મેમરી લે છે અને તેને પાછી આપતી નથી. સમય જતાં, સક્રિય રીતે ચાલતા VMમાં, આ કાઉન્ટર્સના મૂલ્યો રૂપરેખાંકિત મેમરીની માત્રા સુધી પહોંચે છે અને ત્યાં જ રહે છે.

ઝીરો — VM RAM (KB) ની માત્રા, જેમાં શૂન્ય હોય છે. આવી મેમરીને હાઇપરવાઇઝર દ્વારા મફત ગણવામાં આવે છે અને અન્ય વર્ચ્યુઅલ મશીનોને આપી શકાય છે. ગેસ્ટ OS એ શૂન્ય મેમરી પર કંઈક લખ્યા પછી, તે વપરાશમાં જાય છે અને પાછું પાછું આવતું નથી.

આરક્ષિત ઓવરહેડ — VM RAM નો જથ્થો, (KB) VM ઓપરેશન માટે હાઇપરવાઇઝર દ્વારા આરક્ષિત. આ એક નાની રકમ છે, પરંતુ તે હોસ્ટ પર ઉપલબ્ધ હોવી જોઈએ, અન્યથા VM શરૂ થશે નહીં.

બલૂન - બલૂન ડ્રાઈવરનો ઉપયોગ કરીને VMમાંથી જપ્ત કરવામાં આવેલ RAM (KB)નો જથ્થો.

સંકુચિત - RAM (KB) ની માત્રા જે સંકુચિત હતી.

અદલાબદલ - RAM (KB) ની માત્રા જે, સર્વર પર ભૌતિક મેમરીના અભાવને કારણે, ડિસ્ક પર ખસેડવામાં આવી હતી.
બલૂન અને અન્ય મેમરી રીક્લેમેશન ટેક્નિક કાઉન્ટર્સ શૂન્ય છે.

આ રીતે મેમરી કાઉન્ટર્સ સાથેનો ગ્રાફ 150 GB RAM સાથે સામાન્ય રીતે કાર્યરત VM માટે જેવો દેખાય છે.

નીચેના ગ્રાફમાં, VM ને સ્પષ્ટ સમસ્યાઓ છે. ગ્રાફ હેઠળ, તમે જોઈ શકો છો કે આ VM માટે, RAM સાથે કામ કરવા માટેની બધી વર્ણવેલ તકનીકોનો ઉપયોગ કરવામાં આવ્યો હતો. આ VM માટેનો બલૂન Consumed કરતા ઘણો મોટો છે. હકીકતમાં, VM જીવંત કરતાં વધુ મૃત છે.

ESXTOP

CPU ની જેમ, જો આપણે હોસ્ટ પરની પરિસ્થિતિનું તેમજ 2 સેકન્ડ સુધીના અંતરાલ સાથે તેની ગતિશીલતાનું ઝડપથી મૂલ્યાંકન કરવા માંગતા હોય, તો આપણે ESXTOP નો ઉપયોગ કરવો જોઈએ.

મેમરી દ્વારા ESXTOP સ્ક્રીનને "m" કી સાથે બોલાવવામાં આવે છે અને તે આના જેવો દેખાય છે (ક્ષેત્રો B, D, H, J, K, L, O પસંદ કરેલ છે):

નીચેના પરિમાણો અમારા માટે રસપ્રદ રહેશે:

મેમ ઓવરકમિટ સરેરાશ - હોસ્ટ પર 1, 5 અને 15 મિનિટ માટે મેમરી ઓવરસબ્સ્ક્રિપ્શનનું સરેરાશ મૂલ્ય. જો તે શૂન્યથી ઉપર છે, તો પછી શું થઈ રહ્યું છે તે જોવા માટે આ એક પ્રસંગ છે, પરંતુ હંમેશા સમસ્યાઓનું સૂચક નથી.

લીટીઓમાં PMEM/MB и VMKMEM/MB - સર્વરની ભૌતિક મેમરી અને VMkernel માટે ઉપલબ્ધ મેમરી વિશેની માહિતી. અહીં રસપ્રદમાંથી તમે મિનફ્રી (MB માં), મેમરીમાં હોસ્ટની સ્થિતિ (અમારા કિસ્સામાં, ઉચ્ચ) નું મૂલ્ય જોઈ શકો છો.

લાઇનમાં NUMA/MB તમે NUMA નોડ્સ (સોકેટ્સ) દ્વારા RAM નું વિતરણ જોઈ શકો છો. આ ઉદાહરણમાં, વિતરણ અસમાન છે, જે, સૈદ્ધાંતિક રીતે, ખૂબ સારું નથી.

નીચે આપેલ મેમરી રીક્લેમેશન તકનીકો પરના સામાન્ય સર્વર આંકડા છે:

PSHARE/MB TPS આંકડા છે;

સ્વેપ/એમબી - ઉપયોગના આંકડા સ્વેપ કરો;

ઝીપ/એમબી - મેમરી પૃષ્ઠ કમ્પ્રેશન આંકડા;

MEMCTL/MB - બલૂન ડ્રાઈવર વપરાશના આંકડા.

વ્યક્તિગત VM માટે, અમને નીચેની માહિતીમાં રસ હોઈ શકે છે. પ્રેક્ષકોને મૂંઝવણમાં ન આવે તે માટે મેં VM નામો છુપાવ્યા :). જો ESXTOP મેટ્રિક vSphere માં કાઉન્ટર જેવું જ હોય, તો હું તેને અનુરૂપ કાઉન્ટર આપું છું.

MEMSZ — VM (MB) પર રૂપરેખાંકિત મેમરીનો જથ્થો.
MEMSZ = GRANT + MCTLSZ + SWCUR + અસ્પૃશ્ય.

અનુદાન - MB ને આપવામાં આવ્યું.

ટીસીએચડી — MB માં સક્રિય.

MCTL? - VM પર બલૂન ડ્રાઇવર ઇન્સ્ટોલ કરેલ છે કે કેમ.

MCTLSZ - બલૂન થી MB.

MCTLGT — RAM (MB) નો જથ્થો જે ESXi VM માંથી બલૂન ડ્રાઈવર (Memctl ટાર્ગેટ) દ્વારા લેવા માંગે છે.

MCTLMAX - બલૂન ડ્રાઈવર દ્વારા ESXi VMમાંથી મહત્તમ RAM (MB) લઈ શકે છે.

SWCUR — સ્વેપ ફાઇલમાંથી VM ને ફાળવેલ RAM (MB) ની વર્તમાન રકમ.

S.W.G.T. - RAM (MB) નો જથ્થો જે ESXi સ્વેપ ફાઇલ (સ્વેપ ટાર્ગેટ)માંથી VM ને આપવા માંગે છે.

ઉપરાંત, ESXTOP દ્વારા, તમે VM ના NUMA ટોપોલોજી વિશે વધુ વિગતવાર માહિતી જોઈ શકો છો. આ કરવા માટે, D, G ફીલ્ડ્સ પસંદ કરો:

એન.એન.એચ. – NUMA નોડ્સ કે જેના પર VM સ્થિત છે. અહીં તમે તરત જ વિશાળ vm જોઈ શકો છો, જે એક NUMA નોડ પર ફિટ નથી.

NRMEM - VM રિમોટ NUMA નોડમાંથી કેટલી મેગાબાઇટ્સ મેમરી લે છે.

NLMEM - VM સ્થાનિક NUMA નોડમાંથી કેટલી મેગાબાઇટ્સ મેમરી લે છે.

N%L - સ્થાનિક NUMA નોડ પર VM મેમરીની ટકાવારી (જો 80% કરતા ઓછી હોય, તો પ્રદર્શન સમસ્યાઓ આવી શકે છે).

હાઇપરવાઇઝર પર મેમરી

જો હાઇપરવાઇઝર માટેના CPU કાઉન્ટર્સ સામાન્ય રીતે ખાસ રસ ધરાવતા ન હોય, તો પરિસ્થિતિ મેમરી સાથે ઉલટી થાય છે. VM પર ઉચ્ચ મેમરીનો ઉપયોગ હંમેશા પર્ફોર્મન્સ સમસ્યાનો સંકેત આપતો નથી, પરંતુ હાઇપરવાઇઝર પર ઉચ્ચ મેમરીનો ઉપયોગ મેમરી વ્યવસ્થાપન તકનીકોને ટ્રિગર કરે છે અને VMમાં પ્રદર્શન સમસ્યાઓનું કારણ બને છે. VM ને સ્વેપમાં પ્રવેશતા અટકાવવા માટે હોસ્ટ મેમરી વપરાશ એલાર્મનું નિરીક્ષણ કરવું આવશ્યક છે.

અદલાબદલી

જો VM સ્વેપમાં હોય, તો તેનું પ્રદર્શન ઘણું ઓછું થાય છે. હોસ્ટ પર ફ્રી રેમ દેખાય તે પછી બલૂનિંગ અને કમ્પ્રેશનના નિશાન ઝડપથી અદૃશ્ય થઈ જાય છે, પરંતુ વર્ચ્યુઅલ મશીન સ્વેપથી સર્વર રેમ પર પાછા ફરવાની કોઈ ઉતાવળમાં નથી.
ESXi 6.0 પહેલાં, સ્વેપમાંથી VM મેળવવાનો એકમાત્ર વિશ્વસનીય અને ઝડપી રસ્તો રીબૂટ કરવાનો હતો (વધુ ચોક્કસ કહીએ તો, કન્ટેનર બંધ/ઓન કરવું). ESXi 6.0 થી શરૂ કરીને, તદ્દન સત્તાવાર ન હોવા છતાં, સ્વેપમાંથી VM દૂર કરવાની એક કાર્યકારી અને વિશ્વસનીય રીત દેખાઈ છે. એક કોન્ફરન્સમાં, હું CPU શેડ્યૂલરના ચાર્જમાંના એક VMware એન્જિનિયર સાથે વાત કરવામાં સક્ષમ હતો. તેમણે પુષ્ટિ કરી કે પદ્ધતિ એકદમ કાર્યકારી અને સલામત છે. અમારા અનુભવમાં, તેની સાથે કોઈ સમસ્યા પણ નહોતી.

સ્વેપમાંથી VM દૂર કરવા માટેના વાસ્તવિક આદેશો વર્ણવેલ ડંકન એપિંગ. હું વિગતવાર વર્ણનનું પુનરાવર્તન નહીં કરું, ફક્ત તેના ઉપયોગનું ઉદાહરણ આપું. જેમ તમે સ્ક્રીનશોટમાં જોઈ શકો છો, ઉલ્લેખિત આદેશોના અમલના થોડા સમય પછી, VM પર સ્વેપ અદૃશ્ય થઈ જાય છે.

ESXi મેમરી મેનેજમેન્ટ ટિપ્સ

છેલ્લે, અહીં કેટલીક ટીપ્સ છે જે તમને RAM ને કારણે VM પ્રદર્શનમાં સમસ્યાઓ ટાળવામાં મદદ કરશે:

• ઉત્પાદક ક્લસ્ટરોમાં મેમરી ઓવરસબ્સ્ક્રિપ્શન ટાળો. ક્લસ્ટરમાં હંમેશા ~20-30% ફ્રી મેમરી હોવી ઇચ્છનીય છે જેથી DRS (અને એડમિનિસ્ટ્રેટર) પાસે દાવપેચ કરવા માટે જગ્યા હોય અને VM સ્થળાંતર દરમિયાન સ્વેપમાં ન જાય. ઉપરાંત, દોષ સહિષ્ણુતા માટે માર્જિન વિશે ભૂલશો નહીં. જ્યારે એક સર્વર નિષ્ફળ જાય અને VM HA નો ઉપયોગ કરીને રીબૂટ થાય ત્યારે તે અપ્રિય છે, અમુક મશીનો સ્વેપમાં પણ જાય છે.
• અત્યંત સંકલિત ઈન્ફ્રાસ્ટ્રક્ચરમાં, અડધાથી વધુ હોસ્ટ મેમરી સાથે VM બનાવવાનો પ્રયાસ ન કરો. આ ફરીથી DRSને કોઈપણ સમસ્યા વિના ક્લસ્ટર સર્વર પર વર્ચ્યુઅલ મશીનો વિતરિત કરવામાં મદદ કરશે. આ નિયમ, અલબત્ત, સાર્વત્રિક નથી :).
• હોસ્ટ મેમરી વપરાશ એલાર્મ માટે જુઓ.
• VM પર VMware ટૂલ્સ ઇન્સ્ટોલ કરવાનું ભૂલશો નહીં અને બલૂનિંગને બંધ કરશો નહીં.
• ઇન્ટર-વીએમ ટીપીએસને સક્ષમ કરવા અને VDI અને પરીક્ષણ વાતાવરણમાં મોટા પૃષ્ઠોને અક્ષમ કરવાનું વિચારો.
• જો VM પ્રદર્શન સમસ્યાઓ અનુભવી રહ્યું હોય, તો તે દૂરસ્થ NUMA નોડમાંથી મેમરીનો ઉપયોગ કરી રહ્યું છે કે કેમ તે જોવા માટે તપાસો.
• શક્ય તેટલી ઝડપથી તમારા VM ને સ્વેપમાંથી બહાર કાઢો! અન્ય વસ્તુઓમાં, જો VM સ્વેપમાં હોય, તો સ્પષ્ટ કારણોસર, સ્ટોરેજ સિસ્ટમ પીડાય છે.

મારા માટે રેમ વિશે એટલું જ છે. નીચે તે લોકો માટે સંબંધિત લેખ છે જેઓ વિગતોમાં ડિગ કરવા માંગે છે. આગામી લેખ storadzh માટે સમર્પિત કરવામાં આવશે.

ઉપયોગી લિંક્સhttp://www.yellow-bricks.com/2015/03/02/what-happens-at-which-vsphere-memory-state/
http://www.yellow-bricks.com/2013/06/14/how-does-mem-minfreepct-work-with-vsphere-5-0-and-up/
https://www.vladan.fr/vmware-transparent-page-sharing-tps-explained/
http://www.yellow-bricks.com/2016/06/02/memory-pages-swapped-can-unswap/
https://kb.vmware.com/s/article/1002586
https://www.vladan.fr/what-is-vmware-memory-ballooning/
https://kb.vmware.com/s/article/2080735
https://kb.vmware.com/s/article/2017642
https://labs.vmware.com/vmtj/vmware-esx-memory-resource-management-swap
https://blogs.vmware.com/vsphere/2013/10/understanding-vsphere-active-memory.html
https://www.vmware.com/support/developer/converter-sdk/conv51_apireference/memory_counters.html
https://docs.vmware.com/en/VMware-vSphere/6.5/vsphere-esxi-vcenter-server-65-monitoring-performance-guide.pdf

સોર્સ: www.habr.com