I denne artikkelen skal vi snakke om ytelsesmålere for RAM i vSphere.
Det virker som om minnet er litt mer entydig enn prosessoren: hvis det oppstår ytelsesproblemer på VM-en, er det vanskelig å ikke legge merke til dem. Men hvis de dukker opp, er det mye vanskeligere å håndtere dem. Men la oss ta det steg for steg.
Litt teori
RAM for virtuelle maskiner hentes fra serverens minne der VMer kjører. Dette er ganske åpenbart :). Hvis serverens RAM ikke er tilstrekkelig for alle som ønsker det, begynner ESXi å bruke teknikker for optimalisering av minneforbruk (memory reclamation techniques). Ellers ville operativsystemene til VM-ene krasjet med minneadgangsfeil.
Hvilke teknikker ESXi bruker, bestemmes av belastningen på RAM:
Minneforhold
Grense
Handlinger
Høy
400% av minFree
Når den øverste grensen er nådd, deles store minnesider opp i små (TPS fungerer i standardmodus).
Clear
100% av minFree
Store minnesider deles opp i små, TPS kjører tvingende.
Soft
64% av minFree
TPS + Ballong
Hard
32% av minFree
TPS + Komprimering + Bytte
Lav
16% av minFree
Komprimering + Bytte + Blokk
minFree er det minnet som er nødvendig for hypervisorens drift.
Frem til og med ESXi 4.1 var minFree som standard fast — 6% av serverens RAM (prosentandelen kunne endres via alternativet Mem.MinFreePct på ESXi). I nyere versjoner begynte minFree å beregnes ut fra vertsmaskinens minnestørrelse i stedet for som en fast prosentandel.
MinFree-verdien (som standard) beregnes som følgende:
Prosentandel av minnet reservert for minFree
Minneområde
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
Gjenstående minne
For eksempel, for en server med 128 GB RAM vil verdien av MinFree være:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
Den faktiske verdien kan variere med et par hundre MB, avhengig av serveren og RAM-en.
Prosentandel av minnet reservert for minFree
Minneområde
Verdi 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%
Gjenstående minne (100 GB)
1024 MB
Normalt anses kun High-tilstand som akseptabel for produktive miljøer. For test- og utviklingsmiljøer kan Clear/Soft-tilstander være akseptable. Hvis det er mindre enn 64% av MinFree på vertsmaskinen, vil VM-ene som kjører på den, absolutt oppleve ytelsesproblemer.
I hver tilstand anvendes bestemte memory reclamation techniques fra TPS, som praktisk talt ikke påvirker VM-ydelsen, til Swapping. Jeg vil forklare dem nærmere.
Transparent Page Sharing (TPS). TPS er groft sagt deduplisering af RAM-siderne på virtuelle maskiner på serveren.
ESXi søger efter identiske RAM-sider blandt de virtuelle maskiner ved at beregne og sammenligne hash-værdierne af siderne og fjerner dublikaterne ved at erstatte dem med henvisninger til den samme side i serverens fysiske hukommelse. Som resultat reduceres forbruget af fysisk hukommelse, og man kan opnå en vis overskrivning af hukommelsen praktisk talt uden tabs i ydeevnen.
Denne mekanisme fungerer kun for hukommelsessider af 4 KB (small pages). Hypervisoren forsøger ikke engang at deduplicere 2 MB (large pages) sider: chancen for at finde identiske sider af den størrelse er ikke stor.
Som standard tildeler ESXi hukommelse til de store sider. Opdeling af store sider til små starter, når tærskeltilstanden High nås og sker tvangsvis, når Clear-tilstanden nås (se hypervisorens tilstandstabel).
Hvis du ønsker, at TPS skal starte arbejdet uden at vente på, at værtens hukommelse fyldes, skal du indstille værdien “Mem.AllocGuestLargePage” til 0 (standard 1). Så vil tildeling af store hukommelsessider til virtuelle maskiner blive deaktiveret.
Fra december 2014 er TPS mellem VM'er som standard deaktiveret i alle ESXi-udgivelser, da der blev fundet en sårbarhed, der teoretisk set kunne give adgang til RAM'en fra en VM til en anden. Yderligere information her. Jeg har ikke set oplysninger om praktisk udnyttelse af TPS-sårbarheden.
TPS-politikken styres via den avancerede mulighed “Mem.ShareForceSalting” på ESXi:
0 — Inter-VM TPS. TPS arbejder på sider mellem forskellige VM'er;
1 – TPS for VM'er med samme værdi for “sched.mem.pshare.salt” i VMX;
2 (standard) – Intra-VM TPS. TPS arbejder på sider inden for VM.
Det giver bestemt mening at deaktivere store sider og aktivere Inter-VM TPS på testmiljøer. Dette kan også bruges til miljøer med mange ensartede VM'er. For eksempel kan besparelsen af fysisk hukommelse på VDI-miljøer nå op på titusinder af procent.
Memory Ballooning. Ballooning er ikke lenger så ufarlig og gjennomsiktig for operativsystemet som VM-teknikken TPS. Men med riktig bruk av Ballooning kan man leve med det og til og med jobbe.
Sammen med Vmware Tools installeres en spesiell driver på VM-en, kalt Balloon Driver (også kjent som vmmemctl). Når hypervisoren begynner å mangle fysisk minne og går over i tilstanden Soft, ber ESXi VM-en om å returnere ubrukt RAM via denne Balloon Driveren. Driveren jobber i sin tur på nivået til operativsystemet og ber om ledig minne derfra. Hypervisoren ser hvilke sider av den fysiske minne som er opptatt av Balloon Driver, tar minnet fra den virtuelle maskinen og returnerer det til verten. Det oppstår ingen problemer med driften av OS, da minnet på OS-nivå er okkupert av Balloon Driver. Som standard kan Balloon Driver ta opptil 65% av minnet til VM-en.
Hvis VMware Tools ikke er installert på VM-en eller Ballooning er deaktivert (jeg anbefaler ikke dette, men det er :), går hypervisoren umiddelbart over til mer aggressive teknikker for minnetrekk. Konklusjon: Sørg for at VMware Tools er installert på VM-en.
Funksjonen til Balloon Driver kan sjekkes fra OS via VMware Tools..
Memory Compression. Denne teknikken brukes når ESXi når Hard-tilstanden. Som navnet antyder, prøver ESXi å komprimere 4 KB sider av RAM til 2 KB og dermed frigjøre litt plass i den fysiske minnen til serveren. Denne teknikken øker betydelig tilgangen til innholdet i RAM-sidene til VM-en, da siden må dekomprimeres først. Noen ganger klarer man ikke å komprimere alle sidene, og selve prosessen tar litt tid. Derfor er denne teknikken ikke veldig effektiv i praksis.
Memory Swapping. Etter en kort fase med Memory Compression, går ESXi nesten uunngåelig (hvis VM-ene ikke har flyttet til andre verter eller skrudd av) over til Swapping. Og hvis det er veldig lite minne igjen (Low-tilstand), slutter hypervisoren også å tildele VM-sider med minne, noe som kan forårsake problemer i gjeste-OSene til VM-en.
Slik fungerer Swapping. Når en virtuell maskin startes, opprettes en fil med .vswp-utvidelse for den. Størrelsen er lik den ikke-reserverte RAM-en til VM-en: det er forskjellen mellom konfigurert og reserverte minne. Når Swapping er aktivert, overfører ESXi minnesider fra den virtuelle maskinen til denne filen og begynner å jobbe med den i stedet for den fysiske minnen på serveren. Selvfølgelig er denne 'minnen' flere størrelsesordener tregere enn faktisk minne, selv om .vswp ligger på rask lagring.
I motsetning til Ballooning, hvor VM-en mister ubrukte sider, kan ved Swapping sider som aktivt brukes av operativsystemet eller applikasjoner i VM-en flyttes til disk. Som et resultat faller ytelsen til VM-en, opp til hengning. VM-en fungerer formelt og kan i det minste riktig stenges fra OS. Hvis du er tålmodig 😉
Hvis VM-ene har gått i Swap, er det en unormal situasjon som best unngås.
Hovedytelsesmålere for minnet til den virtuelle maskinen
Nå har vi nådd kjernen av saken. For å overvåke minnestatusen i VM-en finnes følgende målere:
Aktiv — viser mengden RAM (KB) som VM-en hadde tilgang til i den forrige måleperioden.
Bruk — det samme som Aktive, men i prosent av den konfigurerte RAM-en til VM-en. Beregnes med følgende formel: aktiv ÷ virtual machine configured memory size.
Høy Bruk og Aktiv betyr ikke nødvendigvis at det er ytelsesproblemer med VM-en. Hvis VM-en aggressivt bruker minne (minst får tilgang til det), betyr det ikke at det er mangel på minne. Snarere er det en grunn til å se på hva som skjer i OS.
Det finnes en standard Alarm for Memory Usage for VM-er:
Delt — volumet av RAM i VM-en som er deduplisert ved hjelp av TPS (internt i VM-en eller mellom VM-er).
Tildelt — volumet av fysisk minne på verten (KB) som er tildelt til VM-en. Inkluderer Delt.
Brukt (Tildelt — Delt) — volumet av fysisk minne (KB) som VM-en bruker fra verten. Inkluderer ikke Delt.
Hvis en del av minnet til VM-en tildeles fra swap-filen eller minne er avskåret fra VM-en via Balloon Driver, blir dette ikke inkludert i Tildelt og Brukt.
Høye verdier for Granted og Consumed er helt normalt. Operativsystemet tar gradvis minne fra hypervisoren og gir det ikke tilbake. Over tid nærmer dataene til disse tellerne seg volumet av den konfigurerte minnen, og de forblir der.
Null — volumet av VM RAM (Kbyte) som inneholder nuller. Slikt minne betraktes som ledig av hypervisoren og kan gis til andre virtuelle maskiner. Etter at gjeste-OS har skrevet noe i det nullstilte minnet, må det over til Consumed og kommer ikke tilbake.
Reserved Overhead — volumet av VM RAM (Kbyte) som er reservert av hypervisoren for å få VM til å fungere. Dette er et lite volum, men det må absolutt være tilgjengelig på verten, ellers kan ikke VM starte.
Balloon — volumet av RAM (Kbyte) som er tatt fra VM ved hjelp av Balloon Driver.
Compressed — volumet av RAM (Kbyte) som har blitt komprimert.
Swapped — volumet av RAM (Kbyte) som, på grunn av mangel på fysisk minne på serveren, har flyttet til disken.
Balloon og andre tellere for minnegjenvinning er lik null.
Slik ser grafen med telere for en normalt fungerende VM med 150 GB RAM ut.
Grafen nedenfor viser tydelige problemer for VM. Under grafen kan vi se at alle beskrevne teknikker for minnebehandling har blitt brukt for denne VM. Balloon for denne VM er betydelig større enn Consumed. Faktisk er VM mer død enn levende.
ESXTOP
Som med CPU, hvis vi vil vurdere situasjonen på verten raskt, samt dens dynamikk med intervaller på opptil 2 sekunder, er det best å bruke ESXTOP.
ESXTOP-skjermen for minne aktiveres med 'm'-tasten og ser slik ut (feltene B,D,H,J,K,L,O er valgt):
Følgende parametere vil være interessante for oss:
Mem overcommit avg — gjennomsnittlig minneoverbooking på verten over 1, 5 og 15 minutter. Hvis det er over null, er det grunn til å se hva som skjer, men det er ikke alltid et tegn på problemer.
I linjene PMEM/MB og VMKMEM/MB — informasjon om den fysiske minnen til serveren og minnet tilgjengelig for VMkernel. Her kan vi se minfree-verdien (i MB), tilstanden til verten med hensyn til minne (i vårt tilfelle, høy).
I linjen NUMA/MB kan vi se fordelingen av RAM over NUMA-noder (prosessorer). I dette eksempelet er fordelingen ujevn, noe som i prinsippet ikke er så bra.
Her kjem generell statistikk om serveren vedrørende minnegjenvinningsteknikker:
PSHARE/MB — dette er TPS-statistikk;
SWAP/MB — statistikk for bruk av Swap;
ZIP/MB — statistikk for komprimering av minnesider;
MEMCTL/MB — statistikk for bruk av Balloon Driver.
For individuelle VM-er kan vi være interessert i følgende informasjon. Jeg har skjult VM-navnene for ikke å forvirre publikum :). Hvis ESXTOP-metrikken er lik telleren i vSphere, gir jeg den tilsvarende telleren.
MEMSZ — mengden minne konfigurert på VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.
GRANT — Granted i MB.
TCHD — Active i MB.
MCTL? — er Balloon Driver installert på VM.
MCTLSZ — Balloon i MB.
MCTLGT — mengden RAM (MB) som ESXi ønsker å trekke fra VM gjennom Balloon Driver (Memctl Target).
MCTLMAX — maks mengde RAM (MB) som ESXi kan trekke fra VM gjennom Balloon Driver.
SWCUR — nåværende mengde RAM (MB) tildelt VM fra Swap-filen.
SWGT — mengden RAM (MB) som ESXi ønsker å gi VM fra Swap-filen (Swap Target).
Gjennom ESXTOP kan man også se mer detaljert informasjon om NUMA-topologien til VM. For dette må man velge feltene D,G:
NHN – NUMA-noder der VM er plassert. Her kan man umiddelbart merke wide VM-er som ikke passer inn på én NUMA-node.
NRMEM – hvor mange megabyte minne VM tar fra en fjern NUMA-node.
NLMEM – hvor mange megabyte minne VM tar fra en lokal NUMA-node.
N%L – prosent av minnet til VM på lokal NUMA-node (hvis under 80 % — kan det oppstå ytelsesproblemer).
Minne på hypervisoren
Hvis CPU-tellere på hypervisoren vanligvis ikke er av stor interesse, er situasjonen med minnet den motsatte. Høy minnebruk på VM indikerer ikke alltid et ytelsesproblem, men høy minnebruk på hypervisoren utløser faktisk minnehåndteringsteknikker og forårsaker problemer med ytelsen til VM. Man må overvåke varslene for Host Memory Usage og unngå at VM havner i Swap.
Unswap
Hvis VM har havnet i Swap, vil ytelsen dens bli kraftig redusert. Spor av Ballooning og komprimering forsvinner raskt etter at det blir ledig RAM på verten, men det er ikke hastverk med å komme seg fra Swap tilbake til serverens RAM.
Frem til ESXi 6.0 var den eneste pålitelige og hurtige måten å hente VM fra Swap på å starte den på nytt (mer presist å skru av/på containeren). Fra og med ESXi 6.0 ble det introdusert en metode som, selv om den ikke helt er offisiell, er en fungerende og pålitelig måte å hente VM fra Swap. På en av konferansene klarte jeg å snakke med en av ingeniørene i VMware som jobber med CPU Scheduler. Han bekreftet at metoden er fullt funksjonell og sikker. Vi har heller ikke hatt noen problemer med den i vår erfaring.
Kommandos for å hente VM fra Swap Duncan Epping. Jeg vil ikke gjenta den detaljerte beskrivelsen, bare gi et eksempel på bruken av den. Som vist på skjermen, forsvinner Swap fra VM etter en tid etter at den angitte kommandoen er utført.
Tips for å håndtere RAM på ESXi
Til slutt gir jeg noen tips som kan hjelpe deg med å unngå ytelsesproblemer i VM på grunn av RAM:
- Unngå oversalg av RAM i produksjonsklynger. Det er best å alltid ha ~20-30% ledig minne i klyngen, slik at DRS (og administratoren) har rom for manøvrering, og at VM ikke går i Swap under migrering. Ikke glem å ta hensyn til redundans. Det er ubehagelig når en server svikter, og omstart av VM via HA fører til at noen maskiner også går i Swap.
- I infrastrukturer med høy konsolidering, prøv å IKKE opprette VM med mer enn halvparten av minnet til verten. Dette vil igjen hjelpe DRS med å distribuere virtuelle maskiner på serverne i klyngen uten problemer. Denne regelen er selvfølgelig ikke universell : ).
- Følg med på Alarm for Bruk av Vertens Minne.
- Husk å installere VMware Tools på VM og ikke deaktivere Ballooning.
- Vurder å aktivere Inter-VM TPS og deaktivere Store Sider i VDI-miljøer og testmiljøer.
- Hvis VM har ytelsesproblemer, sjekk om den bruker minne fra en fjern NUMA-node.
- Hent VM fra Swap så raskt som mulig! I tillegg, hvis VM er i Swap, vil lagringssystemet lide av åpenbare grunner.
Det er alt jeg har om RAM. Nedenfor er artikler om emnet for de som ønsker å dykke dypere inn i detaljene. Neste artikkel vil fokusere på lagring.
Nyttige lenker
Kilde: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Lithuanian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish