{"id":35292,"date":"2019-10-31T22:03:28","date_gmt":"2019-10-31T19:03:28","guid":{"rendered":"https:\/\/prohoster.info\/blog\/analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory\/"},"modified":"2019-10-31T22:03:28","modified_gmt":"2019-10-31T19:03:28","slug":"analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory","title":{"rendered":"Analyse af VM-ydeevne i VMware vSphere. Del 2: Memory.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Analyse
\n
\nDel 1. Om CPU<\/a><\/noindex><\/p>\n

I denne artikel taler vi om performance t\u00e6llere for arbejdshukommelse (RAM) i vSphere.
\nDet virker til, at der er mere klarhed omkring hukommelsen end om processoren: hvis VM'erne oplever performanceproblemer, er de sv\u00e6re at undg\u00e5. Men n\u00e5r de opst\u00e5r, er det langt sv\u00e6rere at h\u00e5ndtere dem. Men lad os tage det fra starten. <\/a><\/noindex><\/p>\n

Lidt teori<\/h3>\n

\nDen arbejdshukommelse, der anvendes af virtuelle maskiner, tages fra serverens hukommelse, hvor VM'erne k\u00f8rer. Dette er ganske indlysende :). Hvis serverens arbejdshukommelse ikke er tilstr\u00e6kkelig for alle ans\u00f8gere, begynder ESXi at anvende teknikker til optimering af forbruget af arbejdshukommelse (memory reclamation techniques). Ellers ville operativsystemerne p\u00e5 VM'erne falde med hukommelsesadgangsfejl. <\/p>\n

Hvilke teknikker der skal anvendes, bestemmer ESXi afh\u00e6ngigt af belastningen af arbejdshukommelsen:<\/p>\n

Hukommelsestilstand<\/b><\/p>\n

Gr\u00e6nse<\/b><\/p>\n

Handlinger<\/b><\/p>\n

H\u00f8j<\/p>\n

400% af minFree<\/p>\n

N\u00e5r den \u00f8verste gr\u00e6nse n\u00e5s, opdeles store hukommelsessider i mindre (TPS fungerer i standardtilstand).<\/p>\n

Ryd<\/p>\n

100% af minFree<\/p>\n

Store hukommelsessider opdeles i mindre, TPS fungerer tvingende.<\/p>\n

Soft<\/p>\n

64% af minFree<\/p>\n

TPS + Balloon<\/p>\n

Hard<\/p>\n

32% af minFree<\/p>\n

TPS + Compress + Swap<\/p>\n

Lav<\/p>\n

16% af minFree<\/p>\n

Compress + Swap + Block<\/p>\n

Kilde<\/a><\/noindex> <\/p>\n

minFree er den arbejdshukommelse, der er n\u00f8dvendig for hypervisorens drift. <\/p>\n

Indtil ESXi 4.1 var minFree standardfastsat til 6% af serverens samlede m\u00e6ngde arbejdshukommelse (procenten kunne \u00e6ndres via indstillingen Mem.MinFreePct p\u00e5 ESXi). I senere versioner, p\u00e5 grund af den stigende m\u00e6ngde hukommelse p\u00e5 serverne, begyndte minFree at blive beregnet baseret p\u00e5 v\u00e6rtsm\u00e6ngden af hukommelse snarere end som en fast procentdel. <\/p>\n

MinFree-v\u00e6rdien (standard) beregnes som f\u00f8lger:<\/p>\n

Procentdel af hukommelse, der er reserveret til minFree<\/b><\/p>\n

Hukommelsesomr\u00e5de<\/b><\/p>\n

6%<\/p>\n

0-4 GB<\/p>\n

4%<\/p>\n

4-12 GB<\/p>\n

2%<\/p>\n

12-28 GB<\/p>\n

1%<\/p>\n

Tilbagev\u00e6rende hukommelse<\/p>\n

Kilde<\/a><\/noindex><\/p>\n

For eksempel, for en server med 128 GB RAM vil minFree-v\u00e6rdien v\u00e6re som f\u00f8lger:
\nMinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
\nDen faktiske v\u00e6rdi kan variere med et par hundrede MB, afh\u00e6ngigt af serveren og den arbejdshukommelse, der er tilg\u00e6ngelig.<\/p>\n

Procentdel af hukommelse, der er reserveret til minFree<\/b><\/p>\n

Hukommelsesomr\u00e5de<\/b><\/p>\n

V\u00e6rdi for 128 GB<\/b><\/p>\n

6%<\/p>\n

0-4 GB<\/p>\n

245,76 MB<\/p>\n

4%<\/p>\n

4-12 GB<\/p>\n

327,68 MB<\/p>\n

2%<\/p>\n

12-28 GB<\/p>\n

327,68 MB<\/p>\n

1%<\/p>\n

Tilbagev\u00e6rende hukommelse (100 GB)<\/p>\n

1024 MB<\/p>\n

\nFor productive environments, only the High state can usually be considered acceptable. For test and development environments, the Clear\/Soft states may be acceptable. If the remaining RAM on the host is less than 64% MinFree, then VMs running on it will definitely experience performance issues.<\/p>\n

Each state applies specific memory reclamation techniques, starting from TPS, which has virtually no impact on VM performance, to Swapping. I will explain these in more detail. <\/p>\n

Transparent Page Sharing (TPS).<\/b> TPS is roughly speaking, the deduplication of the RAM pages of virtual machines on the server.<\/p>\n

ESXi searches for identical memory pages of virtual machines by calculating and comparing the hash sums of the pages, and removes duplicate pages, replacing them with references to the same page in the server's physical memory. As a result, physical memory consumption is reduced, and some memory overcommitment can be achieved almost without a decrease in performance.<\/p>\n

\"Analyse
\nKilde<\/a><\/noindex><\/p>\n

This mechanism only works for memory pages of 4 KB (small pages). The hypervisor does not even attempt to deduplicate 2 MB (large pages): the chance of finding identical pages of that size is low.<\/p>\n

By default, ESXi allocates memory in large pages. The splitting of large pages into small ones begins when the High state threshold is reached and occurs forcibly when the Clear state is reached (see the hypervisor state table).<\/p>\n

If you want TPS to start working without waiting for the host's RAM to fill up, you need to set the value in Advanced Options ESXi to \u201cMem.AllocGuestLargePage\u201d<\/i> to 0 (default is 1). Then, the allocation of large memory pages for virtual machines will be disabled.<\/p>\n

Since December 2014, in all ESXi releases, TPS between VMs is disabled by default, as a vulnerability was found that theoretically allows access to the RAM of one VM from another VM. Details here. I have not encountered information regarding the practical implementation of exploiting the TPS vulnerability.<\/p>\n

The TPS policy is controlled through the advanced option \u201cMem.ShareForceSalting\u201d<\/i> on ESXi:
\n0 \u2014 Inter-VM TPS. TPS works for pages of different VMs;
\n1 \u2013 TPS for VMs with the same value of \u201csched.mem.pshare.salt\u201d in VMX;
\n2 (default) \u2013 Intra-VM TPS. TPS works for pages within the same VM.<\/p>\n

Det giver bestemt mening at deaktivere store sider og aktivere Inter-VM TPS p\u00e5 testmilj\u00f8er. Dette kan ogs\u00e5 anvendes til milj\u00f8er med et stort antal ensartede VM'er. For eksempel kan der i VDI-ops\u00e6tninger spares op til flere procent af den fysiske hukommelse. <\/p>\n

Memory Ballooning.<\/b> Ballooning er ikke l\u00e6ngere en s\u00e5 harml\u00f8s og gennemsigtig teknik for operativsystemet i VM'erne som TPS. Men med korrekt anvendelse kan man leve med og endda arbejde med Ballooning.<\/p>\n

Sammen med VMware Tools installeres der en specialdriver p\u00e5 VM'en, kaldet Balloon Driver (ogs\u00e5 kendt som vmmemctl). N\u00e5r hypervisoren begynder at mangle fysisk hukommelse og g\u00e5r over i en Soft-tilstand, beder ESXi VM'en om at returnere ubrugt RAM gennem denne Balloon Driver. Driveren opererer p\u00e5 operativsystemniveau og anmoder om ledig hukommelse fra det. Hypervisoren ser, hvilke sider af den fysiske hukommelse Balloon Driver har taget, tilbageholder hukommelsen fra den virtuelle maskine og returnerer den til v\u00e6rten. Der opst\u00e5r ingen problemer med operativsystemets funktion, da hukommelsen p\u00e5 operativsystemniveau er optaget af Balloon Driver'en. Som standard kan Balloon Driver tage op til 65% af hukommelsen i VM'en.<\/p>\n

Hvis VMware Tools ikke er installeret p\u00e5 VM'en eller Ballooning er deaktiveret (jeg anbefaler ikke dette, men der er KB<\/a><\/noindex>:), g\u00e5r hypervisoren straks over til mere strikse teknikker til erobring af hukommelse. Konklusion: S\u00f8rg for, at VMware Tools er installeret p\u00e5 VM'en.<\/p>\n

\"Analyse
\nFunktionen af Balloon Driver'en kan kontrolleres fra operativsystemet via VMware Tools.<\/i>.<\/p>\n

Memory Compression.<\/b> Denne teknik anvendes, n\u00e5r ESXi n\u00e5r tilstande Hard. Som navnet antyder, fors\u00f8ger ESXi at komprimere 4 KB hukommelsessider til 2 KB for p\u00e5 den m\u00e5de at frig\u00f8re lidt plads i den fysiske hukommelse p\u00e5 serveren. Denne teknik \u00f8ger betydeligt adgangstiden til indholdet af hukommelsessiderne i VM'en, da siden skal dekomprimeres f\u00f8rst. Nogle gange lykkes det ikke at komprimere alle siderne, og selve processen tager noget tid. Derfor er denne teknik i praksis ikke s\u00e6rlig effektiv.<\/p>\n

Memory Swapping.<\/b> Efter en kort fase med Memory Compression g\u00e5r ESXi n\u00e6sten uundg\u00e5eligt (hvis VM'erne ikke flyttes til andre v\u00e6rter eller slukkes) over til Swapping. Og hvis der er meget lidt hukommelse tilbage (tilstand Low), stopper hypervisoren ogs\u00e5 med at tildele VM'erne hukommelsessider, hvilket kan for\u00e5rsage problemer i g\u00e6steoperativsystemerne i VM'erne.<\/p>\n

S\u00e5dan fungerer Swapping. N\u00e5r en virtuel maskine startes, oprettes der en fil med .vswp-udvidelsen. St\u00f8rrelsen svarer til den ikke-reserverede RAM i VM: det er forskellen mellem den konfigurerede og reserverede hukommelse. Under Swapping overf\u00f8rer ESXi hukommelsessider fra den virtuelle maskine til denne fil og begynder at arbejde med den i stedet for serverens fysiske hukommelse. Selvf\u00f8lgelig er denne \u201ehukommelse\u201c adskillige ordnede langsommere end den rigtige, selvom .vswp ligger p\u00e5 hurtig lagring.<\/p>\n

I mods\u00e6tning til Ballooning, hvor ikke-brugte sider fjernes fra VM, kan sider, der aktivt bruges af operativsystemet eller programmerne inde i VM, flytte til disk under Swapping. Dette medf\u00f8rer, at VMs ydeevne falder til det punkt, hvor den n\u00e6sten fryser. VM'en fungerer formelt, og den kan som mindst korrekt slukkes fra OS. Hvis du er t\u00e5lmodig \ud83d\ude09<\/p>\n

Hvis VMen er g\u00e5et i Swap - er dette en us\u00e6dvanlig situation, som helst b\u00f8r undg\u00e5s.<\/p>\n

De vigtigste hukommelsesydelsesm\u00e5l for den virtuelle maskine<\/h3>\n

\nNu er vi kommet til det vigtigste. For at overv\u00e5ge hukommelsestilstanden i VM'en findes f\u00f8lgende m\u00e5linger:<\/p>\n

Aktiv<\/b> \u2014 viser m\u00e6ngden af RAM (KB), som VM'en har haft adgang til i den foreg\u00e5ende m\u00e5leperiode.<\/p>\n

Brug<\/b> \u2014 det samme som Aktiv, men i procent af den konfigurerede hukommelse for VM'en. Beregnes efter f\u00f8lgende formel: aktiv \u00f7 konfigureret hukommelsesst\u00f8rrelse for virtuel maskine.
\nH\u00f8j brug og Aktiv er ikke altid indikatorer for ydeevneproblemer i VM'en. Hvis VM'en aggressivt bruger hukommelse (i det mindste f\u00e5r adgang til den), betyder det ikke, at der mangler hukommelse. Snarere er det en grund til at se, hvad der sker i OS.
\nDer er en standard Alarm for Memory Usage for VM'er:<\/p>\n

\"Analyse
\n
\nDelt<\/b> \u2014 m\u00e6ngden af RAM i VM'en, der er deduplikeret ved hj\u00e6lp af TPS (inden i VM eller mellem VM'er).<\/p>\n

Givet<\/b> \u2014 m\u00e6ngden af fysisk hukommelse p\u00e5 v\u00e6rten (KB), som er givet til VM'en. Inkluderer Deling.<\/p>\n

Forbrugt<\/b> (Givet \u2014 Delt) \u2014 m\u00e6ngden af fysisk hukommelse (KB), som VM'en forbruger fra v\u00e6rten. Inkluderer ikke Delt.<\/p>\n

Hvis en del af hukommelsen i VM'en tildeles ikke fra den fysiske hukommelse p\u00e5 v\u00e6rten, men fra swap-filen, eller hvis hukommelsen er taget fra VM'en via Balloon Driver, t\u00e6lles denne m\u00e6ngde ikke med i Givet og Forbrugt.
\nH\u00f8je v\u00e6rdier for Granted og Consumed er helt normale. Operativsystemet tager gradvist hukommelse fra hypervisoren og returnerer den ikke. Over tid n\u00e6rmer v\u00e6rdierne for disse t\u00e6llere sig det konfigurerede hukommelsesbel\u00f8b for den aktive virtuelle maskine, og de forbliver der.<\/p>\n

Zero<\/b> \u2014 m\u00e6ngden af RAM i VM'en (KB), der indeholder nuller. Denne hukommelse betragtes af hypervisoren som fri og kan gives til andre virtuelle maskiner. N\u00e5r g\u00e6st OS'et har skrevet noget til den nulstillede hukommelse, g\u00e5r det over i Consumed og returneres ikke.<\/p>\n

Reserved Overhead<\/b> \u2014 m\u00e6ngden af RAM i VM'en (KB), der er reserveret af hypervisoren til drift af VM'en. Det er en lille m\u00e6ngde, men den skal v\u00e6re tilg\u00e6ngelig p\u00e5 v\u00e6rten, ellers kan VM'en ikke starte.<\/p>\n

Balloon<\/b> \u2014 m\u00e6ngden af RAM (KB), der er taget fra VM'en ved hj\u00e6lp af Balloon Driver.<\/p>\n

Compressed<\/b> \u2014 m\u00e6ngden af RAM (KB), som er lykkedes at komprimere.<\/p>\n

Swapped<\/b> \u2014 m\u00e6ngden af RAM (KB), som er flyttet til disk p\u00e5 grund af mangel p\u00e5 fysisk hukommelse p\u00e5 serveren.
\nBalloon og de andre t\u00e6llere for memory reclamation techniques er nul.<\/p>\n

S\u00e5dan ser grafen ud med t\u00e6llerne for en normal fungerende VM med 150 GB RAM.<\/p>\n

\"Analyse
\n
\nP\u00e5 grafen nedenfor har VM'en tydelige problemer. Under grafen kan man se, at alle de beskrevne teknikker til arbejde med RAM er blevet anvendt for denne VM. Balloon for denne VM er meget st\u00f8rre end Consumed. Faktisk er VM'en mere d\u00f8d end levende. <\/p>\n

\"Analyse
\n<\/p>\n

ESXTOP<\/h3>\n

\nSom med CPU, hvis vi hurtigt vil vurdere situationen p\u00e5 v\u00e6rten s\u00e5vel som dens dynamik med intervaller p\u00e5 op til 2 sekunder, b\u00f8r vi bruge ESXTOP.<\/p>\n

ESXTOP-sk\u00e6rmen for hukommelse aktiveres med tasten \"m\" og ser s\u00e5ledes ud (felterne B, D, H, J, K, L, O er valgt):<\/p>\n

\"Analyse
\n
\nDe f\u00f8lgende parametre vil v\u00e6re interessante for os: <\/p>\n

Mem overcommit avg<\/b> \u2014 gennemsnittet for hukommelsesovercommit p\u00e5 v\u00e6rten over 1, 5 og 15 minutter. Hvis det er over nul, er det grund til at kigge n\u00e6rmere, men det er ikke altid en indikator p\u00e5 problemer.<\/p>\n

I linjerne PMEM\/MB<\/b> og VMKMEM\/MB<\/b> \u2014 information om den fysiske hukommelse p\u00e5 serveren og hukommelsen tilg\u00e6ngelig for VMkernel. Her kan man se minfree v\u00e6rdien (i MB), v\u00e6rtsstatus for hukommelse (i vores tilf\u00e6lde, high).<\/p>\n

I linjen NUMA\/MB<\/b> kan man se fordelingen af RAM over NUMA-noder (sokler). I dette eksempel er fordelingen uj\u00e6vn, hvilket i princippet ikke er s\u00e6rlig godt.<\/p>\n

Her er den samlede statistik for serveren vedr\u00f8rende memory reclamation teknikker:<\/p>\n

PSHARE\/MB<\/b> \u2014 er TPS-statistik;<\/p>\n

SWAP\/MB<\/b> \u2014 statistikken for brugen af Swap;<\/p>\n

ZIP\/MB<\/b> \u2014 statistikken for komprimering af hukommelsessider;<\/p>\n

MEMCTL\/MB<\/b> \u2014 statistikken for brugen af Balloon Driver.<\/p>\n

For hver enkelt VM kan vi v\u00e6re interesseret i f\u00f8lgende oplysninger. Jeg har skjult navnene p\u00e5 VM'erne for ikke at forvirre publikum:). Hvis metrikken ESXTOP svarer til t\u00e6lleren i vSphere, bringer jeg den relevante t\u00e6ller. <\/p>\n

MEMSZ<\/b> \u2014 den m\u00e6ngde hukommelse, der er konfigureret til VM'en (MB).
\nMEMSZ = GRANT + MCTLSZ + SWCUR + untouched.<\/p>\n

GRANT<\/b> \u2014 Granted i MB.<\/p>\n

TCHD<\/b> \u2014 Active i MB.<\/p>\n

MCTL?<\/b> \u2014 er Balloon Driver installeret p\u00e5 VM'en.<\/p>\n

MCTLSZ<\/b> \u2014 Balloon i MB.<\/p>\n

MCTLGT<\/b> \u2014 den m\u00e6ngde RAM (MB), som ESXi \u00f8nsker at inddrage fra VM'en via Balloon Driver (Memctl Target).<\/p>\n

MCTLMAX<\/b> \u2014 den maksimale m\u00e6ngde RAM (MB), som ESXi kan inddrage fra VM'en via Balloon Driver.<\/p>\n

SWCUR<\/b> \u2014 den aktuelle m\u00e6ngde RAM (MB), der er tildelt VM'en fra Swap-filen. <\/p>\n

SWGT<\/b> \u2014 den m\u00e6ngde RAM (MB), som ESXi \u00f8nsker at tildele VM'en fra Swap-filen (Swap Target).<\/p>\n

Det er ogs\u00e5 muligt at se mere detaljeret information om NUMA-topologien for VM'en via ESXTOP. For dette skal du v\u00e6lge felterne D,G:<\/p>\n

\"Analyse
\n
\nNHN<\/b> \u2013 NUMA-noderne, hvor VM'en er placeret. Her kan man straks bem\u00e6rke brede VM'er, som ikke kan placeres p\u00e5 \u00e9n NUMA-node.<\/p>\n

NRMEM<\/b> \u2013 hvor mange megabyte hukommelse VM'en tager fra den fjerne NUMA-node.<\/p>\n

NLMEM<\/b> \u2013 hvor mange megabyte hukommelse VM'en tager fra den lokale NUMA-node.<\/p>\n

N%L<\/b> \u2013 procentdelen af hukommelse VM'en bruger p\u00e5 den lokale NUMA-node (hvis mindre end 80% \u2014 kan der opst\u00e5 problemer med ydeevnen).<\/p>\n

Hukommelse p\u00e5 hypervisoren<\/h3>\n

\nHvis CPU-t\u00e6llerne p\u00e5 hypervisoren normalt ikke er af s\u00e6rlig interesse, s\u00e5 er situationen med hukommelsen den modsatte. H\u00f8j hukommelsesforbrug p\u00e5 VM'en indikerer ikke altid et problem med ydeevnen, men h\u00f8j hukommelsesforbrug p\u00e5 hypervisoren aktiverer hukommelsesh\u00e5ndteringsteknikker og for\u00e5rsager problemer med VM'ens ydeevne. Man skal overv\u00e5ge alarmene for Host Memory Usage og undg\u00e5, at VM'en g\u00e5r i Swap.<\/p>\n

\"Analyse
\n
\n\"Analyse
\n<\/p>\n

Unswap<\/h3>\n

\nHvis VM'en g\u00e5r i Swap, falder dens ydeevne kraftigt. Spor af Ballooning og kompression forsvinder hurtigt, n\u00e5r der bliver tilstr\u00e6kkelig ledig RAM p\u00e5 v\u00e6rten, men VM'en skynder sig ikke tilbage fra Swap til serverens RAM.
\nIndtil ESXi 6.0 var den eneste p\u00e5lidelige og hurtige m\u00e5de at f\u00e5 VM'er ud af Swap p\u00e5 at genstarte (mere pr\u00e6cist slukke\/t\u00e6nde for containeren). Fra og med ESXi 6.0 er der dog udviklet en metode, der, selvom den ikke er helt officielt anerkendt, er b\u00e5de funktionel og p\u00e5lidelig til at f\u00e5 VM'er ud af Swap. P\u00e5 en af konferencerne fik jeg mulighed for at tale med en af VMware's ingeni\u00f8rer, der arbejder med CPU-scheduler. Han bekr\u00e6ftede, at metoden virker og er sikker. I vores erfaring har vi ikke oplevet problemer med den.<\/p>\n

De faktiske kommandoer til at f\u00e5 VM'er ud af Swap beskrev<\/a><\/noindex> Duncan Epping. Jeg vil ikke gentage den detaljerede beskrivelse, men blot give et eksempel p\u00e5 dens anvendelse. Som det fremg\u00e5r af sk\u00e6rmbillede, forsvinder Swap p\u00e5 VM'en efter et stykke tid efter at have k\u00f8rt den angivne kommando.<\/p>\n

\"Analyse
\n<\/p>\n

Tips til administration af RAM p\u00e5 ESXi<\/h3>\n

\nTil slut vil jeg give nogle r\u00e5d, der kan hj\u00e6lpe dig med at undg\u00e5 ydeevneproblemer med VM'er p\u00e5 grund af RAM:<\/p>\n