I denne artikel taler vi om performance tællere for arbejdshukommelse (RAM) i vSphere.
Det virker til, at der er mere klarhed omkring hukommelsen end om processoren: hvis VM'erne oplever performanceproblemer, er de svære at undgå. Men når de opstår, er det langt sværere at håndtere dem. Men lad os tage det fra starten.
Lidt teori
Den arbejdshukommelse, der anvendes af virtuelle maskiner, tages fra serverens hukommelse, hvor VM'erne kører. Dette er ganske indlysende :). Hvis serverens arbejdshukommelse ikke er tilstrækkelig for alle ansøgere, begynder ESXi at anvende teknikker til optimering af forbruget af arbejdshukommelse (memory reclamation techniques). Ellers ville operativsystemerne på VM'erne falde med hukommelsesadgangsfejl.
Hvilke teknikker der skal anvendes, bestemmer ESXi afhængigt af belastningen af arbejdshukommelsen:
Hukommelsestilstand
Grænse
Handlinger
Høj
400% af minFree
Når den øverste grænse nås, opdeles store hukommelsessider i mindre (TPS fungerer i standardtilstand).
Ryd
100% af minFree
Store hukommelsessider opdeles i mindre, TPS fungerer tvingende.
Soft
64% af minFree
TPS + Balloon
Hard
32% af minFree
TPS + Compress + Swap
Lav
16% af minFree
Compress + Swap + Block
minFree er den arbejdshukommelse, der er nødvendig for hypervisorens drift.
Indtil ESXi 4.1 var minFree standardfastsat til 6% af serverens samlede mængde arbejdshukommelse (procenten kunne ændres via indstillingen Mem.MinFreePct på ESXi). I senere versioner, på grund af den stigende mængde hukommelse på serverne, begyndte minFree at blive beregnet baseret på værtsmængden af hukommelse snarere end som en fast procentdel.
MinFree-værdien (standard) beregnes som følger:
Procentdel af hukommelse, der er reserveret til minFree
Hukommelsesområde
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
Tilbageværende hukommelse
For eksempel, for en server med 128 GB RAM vil minFree-værdien være som følger:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
Den faktiske værdi kan variere med et par hundrede MB, afhængigt af serveren og den arbejdshukommelse, der er tilgængelig.
Procentdel af hukommelse, der er reserveret til minFree
Hukommelsesområde
Værdi for 128 GB
6%
0-4 GB
245,76 MB
4%
4-12 GB
327,68 MB
2%
12-28 GB
327,68 MB
1%
Tilbageværende hukommelse (100 GB)
1024 MB
For 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.
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.
Transparent Page Sharing (TPS). TPS is roughly speaking, the deduplication of the RAM pages of virtual machines on the server.
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.
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.
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).
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 “Mem.AllocGuestLargePage” to 0 (default is 1). Then, the allocation of large memory pages for virtual machines will be disabled.
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.
The TPS policy is controlled through the advanced option “Mem.ShareForceSalting” on ESXi:
0 — Inter-VM TPS. TPS works for pages of different VMs;
1 – TPS for VMs with the same value of “sched.mem.pshare.salt” in VMX;
2 (default) – Intra-VM TPS. TPS works for pages within the same VM.
Det giver bestemt mening at deaktivere store sider og aktivere Inter-VM TPS på testmiljøer. Dette kan også anvendes til miljøer med et stort antal ensartede VM'er. For eksempel kan der i VDI-opsætninger spares op til flere procent af den fysiske hukommelse.
Memory Ballooning. Ballooning er ikke længere en så harmløs og gennemsigtig teknik for operativsystemet i VM'erne som TPS. Men med korrekt anvendelse kan man leve med og endda arbejde med Ballooning.
Sammen med VMware Tools installeres der en specialdriver på VM'en, kaldet Balloon Driver (også kendt som vmmemctl). Når hypervisoren begynder at mangle fysisk hukommelse og går over i en Soft-tilstand, beder ESXi VM'en om at returnere ubrugt RAM gennem denne Balloon Driver. Driveren opererer på 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ærten. Der opstår ingen problemer med operativsystemets funktion, da hukommelsen på operativsystemniveau er optaget af Balloon Driver'en. Som standard kan Balloon Driver tage op til 65% af hukommelsen i VM'en.
Hvis VMware Tools ikke er installeret på VM'en eller Ballooning er deaktiveret (jeg anbefaler ikke dette, men der er :), går hypervisoren straks over til mere strikse teknikker til erobring af hukommelse. Konklusion: Sørg for, at VMware Tools er installeret på VM'en.
Funktionen af Balloon Driver'en kan kontrolleres fra operativsystemet via VMware Tools..
Memory Compression. Denne teknik anvendes, når ESXi når tilstande Hard. Som navnet antyder, forsøger ESXi at komprimere 4 KB hukommelsessider til 2 KB for på den måde at frigøre lidt plads i den fysiske hukommelse på serveren. Denne teknik øger betydeligt adgangstiden til indholdet af hukommelsessiderne i VM'en, da siden skal dekomprimeres først. Nogle gange lykkes det ikke at komprimere alle siderne, og selve processen tager noget tid. Derfor er denne teknik i praksis ikke særlig effektiv.
Memory Swapping. Efter en kort fase med Memory Compression går ESXi næsten uundgåeligt (hvis VM'erne ikke flyttes til andre værter eller slukkes) over til Swapping. Og hvis der er meget lidt hukommelse tilbage (tilstand Low), stopper hypervisoren også med at tildele VM'erne hukommelsessider, hvilket kan forårsage problemer i gæsteoperativsystemerne i VM'erne.
Sådan fungerer Swapping. Når en virtuel maskine startes, oprettes der en fil med .vswp-udvidelsen. Størrelsen svarer til den ikke-reserverede RAM i VM: det er forskellen mellem den konfigurerede og reserverede hukommelse. Under Swapping overfører ESXi hukommelsessider fra den virtuelle maskine til denne fil og begynder at arbejde med den i stedet for serverens fysiske hukommelse. Selvfølgelig er denne „hukommelse“ adskillige ordnede langsommere end den rigtige, selvom .vswp ligger på hurtig lagring.
I modsætning 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ører, at VMs ydeevne falder til det punkt, hvor den næsten fryser. VM'en fungerer formelt, og den kan som mindst korrekt slukkes fra OS. Hvis du er tålmodig 😉
Hvis VMen er gået i Swap - er dette en usædvanlig situation, som helst bør undgås.
De vigtigste hukommelsesydelsesmål for den virtuelle maskine
Nu er vi kommet til det vigtigste. For at overvåge hukommelsestilstanden i VM'en findes følgende målinger:
Aktiv — viser mængden af RAM (KB), som VM'en har haft adgang til i den foregående måleperiode.
Brug — det samme som Aktiv, men i procent af den konfigurerede hukommelse for VM'en. Beregnes efter følgende formel: aktiv ÷ konfigureret hukommelsesstørrelse for virtuel maskine.
Høj brug og Aktiv er ikke altid indikatorer for ydeevneproblemer i VM'en. Hvis VM'en aggressivt bruger hukommelse (i det mindste får adgang til den), betyder det ikke, at der mangler hukommelse. Snarere er det en grund til at se, hvad der sker i OS.
Der er en standard Alarm for Memory Usage for VM'er:
Delt — mængden af RAM i VM'en, der er deduplikeret ved hjælp af TPS (inden i VM eller mellem VM'er).
Givet — mængden af fysisk hukommelse på værten (KB), som er givet til VM'en. Inkluderer Deling.
Forbrugt (Givet — Delt) — mængden af fysisk hukommelse (KB), som VM'en forbruger fra værten. Inkluderer ikke Delt.
Hvis en del af hukommelsen i VM'en tildeles ikke fra den fysiske hukommelse på værten, men fra swap-filen, eller hvis hukommelsen er taget fra VM'en via Balloon Driver, tælles denne mængde ikke med i Givet og Forbrugt.
Høje værdier for Granted og Consumed er helt normale. Operativsystemet tager gradvist hukommelse fra hypervisoren og returnerer den ikke. Over tid nærmer værdierne for disse tællere sig det konfigurerede hukommelsesbeløb for den aktive virtuelle maskine, og de forbliver der.
Zero — mængden af RAM i VM'en (KB), der indeholder nuller. Denne hukommelse betragtes af hypervisoren som fri og kan gives til andre virtuelle maskiner. Når gæst OS'et har skrevet noget til den nulstillede hukommelse, går det over i Consumed og returneres ikke.
Reserved Overhead — mængden af RAM i VM'en (KB), der er reserveret af hypervisoren til drift af VM'en. Det er en lille mængde, men den skal være tilgængelig på værten, ellers kan VM'en ikke starte.
Balloon — mængden af RAM (KB), der er taget fra VM'en ved hjælp af Balloon Driver.
Compressed — mængden af RAM (KB), som er lykkedes at komprimere.
Swapped — mængden af RAM (KB), som er flyttet til disk på grund af mangel på fysisk hukommelse på serveren.
Balloon og de andre tællere for memory reclamation techniques er nul.
Sådan ser grafen ud med tællerne for en normal fungerende VM med 150 GB RAM.
På 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ørre end Consumed. Faktisk er VM'en mere død end levende.
ESXTOP
Som med CPU, hvis vi hurtigt vil vurdere situationen på værten såvel som dens dynamik med intervaller på op til 2 sekunder, bør vi bruge ESXTOP.
ESXTOP-skærmen for hukommelse aktiveres med tasten "m" og ser således ud (felterne B, D, H, J, K, L, O er valgt):
De følgende parametre vil være interessante for os:
Mem overcommit avg — gennemsnittet for hukommelsesovercommit på værten over 1, 5 og 15 minutter. Hvis det er over nul, er det grund til at kigge nærmere, men det er ikke altid en indikator på problemer.
I linjerne PMEM/MB og VMKMEM/MB — information om den fysiske hukommelse på serveren og hukommelsen tilgængelig for VMkernel. Her kan man se minfree værdien (i MB), værtsstatus for hukommelse (i vores tilfælde, high).
I linjen NUMA/MB kan man se fordelingen af RAM over NUMA-noder (sokler). I dette eksempel er fordelingen ujævn, hvilket i princippet ikke er særlig godt.
Her er den samlede statistik for serveren vedrørende memory reclamation teknikker:
PSHARE/MB — er TPS-statistik;
SWAP/MB — statistikken for brugen af Swap;
ZIP/MB — statistikken for komprimering af hukommelsessider;
MEMCTL/MB — statistikken for brugen af Balloon Driver.
For hver enkelt VM kan vi være interesseret i følgende oplysninger. Jeg har skjult navnene på VM'erne for ikke at forvirre publikum:). Hvis metrikken ESXTOP svarer til tælleren i vSphere, bringer jeg den relevante tæller.
MEMSZ — den mængde hukommelse, der er konfigureret til VM'en (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.
GRANT — Granted i MB.
TCHD — Active i MB.
MCTL? — er Balloon Driver installeret på VM'en.
MCTLSZ — Balloon i MB.
MCTLGT — den mængde RAM (MB), som ESXi ønsker at inddrage fra VM'en via Balloon Driver (Memctl Target).
MCTLMAX — den maksimale mængde RAM (MB), som ESXi kan inddrage fra VM'en via Balloon Driver.
SWCUR — den aktuelle mængde RAM (MB), der er tildelt VM'en fra Swap-filen.
SWGT — den mængde RAM (MB), som ESXi ønsker at tildele VM'en fra Swap-filen (Swap Target).
Det er også muligt at se mere detaljeret information om NUMA-topologien for VM'en via ESXTOP. For dette skal du vælge felterne D,G:
NHN – NUMA-noderne, hvor VM'en er placeret. Her kan man straks bemærke brede VM'er, som ikke kan placeres på én NUMA-node.
NRMEM – hvor mange megabyte hukommelse VM'en tager fra den fjerne NUMA-node.
NLMEM – hvor mange megabyte hukommelse VM'en tager fra den lokale NUMA-node.
N%L – procentdelen af hukommelse VM'en bruger på den lokale NUMA-node (hvis mindre end 80% — kan der opstå problemer med ydeevnen).
Hukommelse på hypervisoren
Hvis CPU-tællerne på hypervisoren normalt ikke er af særlig interesse, så er situationen med hukommelsen den modsatte. Høj hukommelsesforbrug på VM'en indikerer ikke altid et problem med ydeevnen, men høj hukommelsesforbrug på hypervisoren aktiverer hukommelseshåndteringsteknikker og forårsager problemer med VM'ens ydeevne. Man skal overvåge alarmene for Host Memory Usage og undgå, at VM'en går i Swap.
Unswap
Hvis VM'en går i Swap, falder dens ydeevne kraftigt. Spor af Ballooning og kompression forsvinder hurtigt, når der bliver tilstrækkelig ledig RAM på værten, men VM'en skynder sig ikke tilbage fra Swap til serverens RAM.
Indtil ESXi 6.0 var den eneste pålidelige og hurtige måde at få VM'er ud af Swap på at genstarte (mere præcist slukke/tænde for containeren). Fra og med ESXi 6.0 er der dog udviklet en metode, der, selvom den ikke er helt officielt anerkendt, er både funktionel og pålidelig til at få VM'er ud af Swap. På en af konferencerne fik jeg mulighed for at tale med en af VMware's ingeniører, der arbejder med CPU-scheduler. Han bekræftede, at metoden virker og er sikker. I vores erfaring har vi ikke oplevet problemer med den.
De faktiske kommandoer til at få VM'er ud af Swap Duncan Epping. Jeg vil ikke gentage den detaljerede beskrivelse, men blot give et eksempel på dens anvendelse. Som det fremgår af skærmbillede, forsvinder Swap på VM'en efter et stykke tid efter at have kørt den angivne kommando.
Tips til administration af RAM på ESXi
Til slut vil jeg give nogle råd, der kan hjælpe dig med at undgå ydeevneproblemer med VM'er på grund af RAM:
- Undgå overtegnede RAM i produktionsklynger. Det anbefales altid at have ca. 20-30% fri hukommelse i klyngen, så DRS (og administratoren) har plads til at manøvrere, og at VM'er ikke går i Swap under migreringen. Glem heller ikke aflastningen for fejltolerance. Det er ubehageligt, når en server svigter, og VM'er skal genstartes ved hjælp af HA, mens nogle maskiner også går i Swap.
- I infrastrukturer med høj konsolidering bør du undgå at oprette VM'er med mere end halvdelen af værtens hukommelse. Dette vil igen hjælpe DRS med uden problemer at fordele virtuelle maskiner mellem serverne i klyngen. Denne regel er selvfølgelig ikke universel :).
- Hold øje med alarmen for værtens hukommelsesbrug.
- Husk at installere VMware Tools på VM'erne og deaktivere Ballooning.
- Overvej at aktivere Inter-VM TPS og deaktivere Store Sider i VDI-miljøer og testmiljøer.
- Hvis VM'en oplever ydeevneproblemer, skal du tjekke, om den bruger hukommelse fra en fjern NUMA-nod.
- Få VM'er ud af Swap så hurtigt som muligt! Udover alt andet vil det, hvis VM'en er i Swap, åbenbart påvirke lagerløsningen.
Det var alt, hvad jeg havde at sige om RAM. Nedenfor er artikler om emnet for dem, der ønsker at dykke dybere ned i detaljerne. Den næste artikel vil omhandle lager.
Nyttige links
Kilde: habr.com
