I denne artikkelen vil vi snakke om ytelsestellere for random access memory (RAM) i vSphere.
Det ser ut til at med minne er alt mer klart enn med prosessoren: hvis det oppstår ytelsesproblemer på en VM, er det vanskelig å ikke legge merke til dem. Men hvis de dukker opp, er det mye vanskeligere å håndtere dem. Men først ting først.
Litt teori
RAM-en til virtuelle maskiner hentes fra minnet til serveren som VM-ene kjører på. Dette er ganske åpenbart :). Hvis serverens RAM ikke er nok for alle, begynner ESXi å bruke minnegjenvinningsteknikker. Ellers ville VM-operativsystemene krasje med RAM-tilgangsfeil.
ESXi bestemmer hvilke teknikker som skal brukes avhengig av RAM-belastningen:
Minnestatus
grensen
Aktivitet
Høy
400 % av minFree
Etter å ha nådd den øvre grensen, deles store minnesider i små (TPS fungerer i standardmodus).
Fjern
100 % av minFree
Store minnesider deles opp i små, TPS er tvunget.
Soft
64 % av minFree
TPS + ballong
Hard
32 % av minFree
TPS + Komprimer + Bytt
Lav
16 % av minFree
Komprimer + Bytt + Blokkér
minFree er RAM-en som kreves for at hypervisoren skal kjøre.
Opp til ESXi 4.1 inklusive, ble minFree løst som standard - 6 % av serverens RAM (prosentandelen kan endres via Mem.MinFreePct-alternativet på ESXi). I senere versjoner, på grunn av veksten av minne på servere, begynte minFree å bli beregnet basert på mengden minne til verten, og ikke som en fast prosentverdi.
MinFree-verdien (standard) beregnes som følger:
Prosent av minne reservert for minFree
Minneområde
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
Gjenværende minne
For eksempel, for en server med 128 GB RAM, vil MinFree-verdien være som følger:
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 server og RAM.
Prosent av minne 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%
Gjenværende minne (100 GB)
1024 MB
Vanligvis, for produktive bevoksninger, kan bare høy tilstand anses som normal. For test- og utviklingsbenker kan klare/myke tilstander være akseptable. Hvis RAM-en på verten er mindre enn 64 % MinFree, opplever definitivt de virtuelle maskinene som kjører på den ytelsesproblemer.
I hver tilstand brukes visse minnegjenvinningsteknikker, fra TPS, som praktisk talt ikke har noen effekt på VM-ytelsen, til Swapping. Jeg skal fortelle deg mer om dem.
Transparent sidedeling (TPS). TPS er grovt sett deduplisering av RAM-sider til virtuelle maskiner på serveren.
ESXi søker etter identiske virtuelle maskin-RAM-sider ved å telle og sammenligne hash-summen av sidene, og fjerner dupliserte sider, og erstatter dem med referanser til samme side i serverens fysiske minne. Som et resultat reduseres det fysiske minneforbruket og noe overabonnement på minnet kan oppnås med praktisk talt ingen ytelsespåvirkning.
Denne mekanismen fungerer bare for minnesider på 4 KB i størrelse (små sider). Hypervisoren prøver ikke engang å deduplisere sider på 2 MB (store sider): sjansen for å finne identiske sider av denne størrelsen er ikke stor.
Som standard tildeler ESXi minne til store sider. Å dele opp store sider i små sider begynner når terskelen for høy tilstand er nådd og tvinges når Clear-tilstanden er nådd (se hypervisortilstandstabellen).
Hvis du vil at TPS skal begynne å jobbe uten å vente på at verts-RAM-en skal være full, må du angi verdien i Advanced Options ESXi "Mem.AllocGuestLargePage" til 0 (standard 1). Da vil tildelingen av store minnesider for virtuelle maskiner bli deaktivert.
Siden desember 2014, i alle ESXi-utgivelser, er TPS mellom VM-er deaktivert som standard, da det ble funnet en sårbarhet som teoretisk gir én VM tilgang til RAM-en til en annen VM. Detaljer her. Jeg har ikke kommet over informasjon om den praktiske implementeringen av å utnytte TPS-sårbarheten.
TPS-policy styres via avansert alternativ "Mem.ShareForceSalting" på ESXi:
0 - Inter-VM TPS. TPS fungerer for sider på forskjellige VM-er;
1 – TPS for VM-er med samme "sched.mem.pshare.salt"-verdi i VMX;
2 (standard) – Intra-VM TPS. TPS fungerer for sider inne i en VM.
Det er definitivt fornuftig å deaktivere store sider og aktivere Inter-VM TPS på testbenker. Denne kan også brukes til stands med et stort antall lignende VM-er. For eksempel på stands med VDI kan besparelser i fysisk minne komme opp i titalls prosent.
Minneballongflyging. Ballongflyging er ikke lenger en så ufarlig og gjennomsiktig teknikk for VM-operativsystemet som TPS. Men hvis brukt på riktig måte, kan du leve og til og med jobbe med Ballooning.
Sammen med Vmware Tools er en spesiell driver kalt Balloon Driver (aka vmmemctl) installert på VM. Når hypervisoren begynner å gå tom for fysisk minne og går inn i myk tilstand, ber ESXi VM om å gjenvinne ubrukt RAM gjennom denne ballongdriveren. Driveren fungerer på sin side på operativsystemnivå og ber om ledig minne fra den. Hypervisoren ser hvilke sider med fysisk minne ballongføreren har okkupert, tar minne fra den virtuelle maskinen og returnerer det til verten. Det er ingen problemer med driften av operativsystemet, siden på OS-nivå er minnet okkupert av ballongdriveren. Som standard kan Balloon Driver ta opptil 65 % av VM-minnet.
Hvis VMware Tools ikke er installert på VM eller Ballooning er deaktivert (jeg anbefaler det ikke, men det er :), bytter hypervisoren umiddelbart til strengere teknikker for å fjerne minne. Konklusjon: sørg for at VMware Tools er på VM.
Driften av ballongdriveren kan kontrolleres fra operativsystemet via VMware Tools.
Minnekomprimering. Denne teknikken brukes når ESXi når Hard-tilstanden. Som navnet antyder, prøver ESXi å komprimere en 4KB-side med RAM til 2KB, og dermed frigjøre litt plass i serverens fysiske minne. Denne teknikken øker tilgangstiden til innholdet på VM RAM-sider betydelig, siden siden først må dekomprimeres. Noen ganger kan ikke alle sidene komprimeres og selve prosessen tar litt tid. Derfor er denne teknikken ikke særlig effektiv i praksis.
Bytting av minne. Etter en kort fase med minnekomprimering bytter ESXi nesten uunngåelig (hvis VM-ene ikke har flyttet til andre verter eller ikke er slått av) til Swapping. Og hvis det er veldig lite minne igjen (lav tilstand), slutter hypervisoren også å allokere minnesider til VM, noe som kan forårsake problemer i gjeste-OS til VM.
Dette er hvordan bytte fungerer. Når du slår på en virtuell maskin, opprettes en fil med en .vswp-utvidelse for den. Det er lik størrelse med VMs ureserverte RAM: dette er forskjellen mellom konfigurert og reservert minne. Når Swapping kjører, bytter ESXi virtuelle maskinminnesider inn i denne filen og begynner å jobbe med den i stedet for serverens fysiske minne. Selvfølgelig er slikt "RAM"-minne flere størrelsesordener tregere enn ekte minne, selv om .vswp-en er på rask lagring.
I motsetning til ballongkjøring, når ubrukte sider er hentet fra en VM, kan byttesider som brukes aktivt av operativsystemet eller applikasjoner inne i VM flyttes til disk. Som et resultat synker ytelsen til VM til det frysepunktet. VM-en fungerer formelt, og den kan i det minste deaktiveres fra operativsystemet. Hvis du er tålmodig 😉
Hvis VM-er har gått til Swap, er dette en nødsituasjon som best unngås om mulig.
Grunnleggende ytelsetellere for virtuell maskinminne
Så vi kom til det viktigste. For å overvåke minnetilstanden til VM, er det følgende tellere:
Aktiv — viser mengden RAM (KB) som VM-en fikk tilgang til i forrige måleperiode.
bruk — det samme som Active, men som en prosentandel av den konfigurerte RAM-en til VM. Beregnet ved hjelp av følgende formel: aktiv ÷ virtuell maskin konfigurert minnestørrelse.
Høy bruk og aktiv, henholdsvis, er ikke alltid en indikator på VM-ytelsesproblemer. Hvis VM-en aggressivt bruker minne (i det minste tilgang til det), betyr ikke dette at det ikke er nok minne. Dette er snarere en grunn til å se på hva som skjer i OS.
Det er en standard alarm for minnebruk for virtuelle maskiner:
delt — mengden VM RAM deduplisert ved bruk av TPS (innenfor en VM eller mellom VMer).
gitt — mengden fysisk vertsminne (KB) som ble tildelt VM. Aktiverer Delt.
forbrukes (Granted - Shared) - mengden fysisk minne (KB) som den virtuelle maskinen bruker fra verten. Inkluderer ikke Delt.
Hvis en del av VM-minnet ikke er gitt fra vertens fysiske minne, men fra en byttefil, eller minne hentes fra VM-en gjennom ballongdriveren, tas ikke dette beløpet i betraktning i Granted and Consumed.
Høye gitte og forbrukte verdier er helt normale. Operativsystemet tar gradvis minne fra hypervisoren og gir det ikke tilbake. Over tid, i en aktivt kjørende VM, nærmer verdiene til disse tellerne seg mengden konfigurert minne og forblir der.
Zero — mengden VM RAM (KB), som inneholder nuller. Slikt minne anses som gratis av hypervisoren og kan gis til andre virtuelle maskiner. Etter at gjeste-OS har skrevet noe til nullstilt minne, går det inn i Consumed og går ikke tilbake.
Reservert overhead — mengden VM RAM, (KB) reservert av hypervisoren for VM-drift. Dette er et lite beløp, men det må være tilgjengelig på verten, ellers starter ikke VM.
Ballong — mengden RAM (KB) som er fjernet fra VM ved hjelp av ballongdriver.
Komprimert — mengden RAM (KB) som ble komprimert.
Byttet — mengden RAM (KB), som, på grunn av mangel på fysisk minne på serveren, flyttet til disk.
Tellere for ballong- og andre minnegjenvinningsteknikker er null.
Slik ser grafen ut med minnetellerne til en normalt fungerende VM med 150 GB RAM.
I grafen nedenfor har VM åpenbare problemer. Under grafen kan du se at for denne VM ble alle de beskrevne teknikkene for arbeid med RAM brukt. Ballongen for denne VM-en er mye større enn Consumed. Faktisk er VM mer død enn levende.
ESXTOP
Som med CPU, hvis vi raskt vil vurdere situasjonen på verten, så vel som dens dynamikk med et intervall på opptil 2 sekunder, bør vi bruke ESXTOP.
ESXTOP Memory-skjermbildet kalles opp med "m"-tasten og ser slik ut (feltene B,D,H,J,K,L,O valgt):
Følgende parametere vil være av interesse for oss:
Mem overcommit gj.sn — gjennomsnittlig verdi for overabonnement på minnet på verten i 1, 5 og 15 minutter. Hvis det er over null, så er dette en grunn til å se på hva som skjer, men ikke alltid en indikator på problemer.
I linjer PMEM/MB и VMKMEM/MB — informasjon om det fysiske minnet til serveren og minnet som er tilgjengelig for VMkernel. Blant de interessante tingene her kan du se minfree-verdien (i MB), vertstilstanden i minnet (i vårt tilfelle høy).
På linje NUMA/MB du kan se fordelingen av RAM på tvers av NUMA-noder (sockets). I dette eksemplet er fordelingen ujevn, noe som i prinsippet ikke er særlig bra.
Følgende er generell serverstatistikk for minnegjenvinningsteknikker:
PDEL/MB — dette er TPS-statistikk;
BYTT/MB — Byttebruksstatistikk;
ZIP/MB — komprimeringsstatistikk for minneside;
MEMCTL/MB — Bruksstatistikk for ballongførere.
For individuelle VM-er kan vi være interessert i følgende informasjon. Jeg gjemte navnene på VM-ene for ikke å forvirre publikum :). Hvis ESXTOP-metrikken er lik telleren i vSphere, vil jeg gi den tilsvarende telleren.
MEMSZ — mengde minne konfigurert på VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + urørt.
STIPEND — Innvilget i MB.
TCHD — Aktiv i MByte.
MCTL? — om ballongdriveren er installert på VM-en.
MCTLSZ — Ballong til MB.
MCTLGT — mengden RAM (MBytes) som ESXi ønsker å fjerne fra VM-en gjennom ballongdriveren (Memctl Target).
MCTLMAX — den maksimale mengden RAM (MByte) som ESXi kan fjerne fra en VM gjennom ballongdriveren.
SWCUR — gjeldende mengde RAM (MBytes) som er allokert til VM-en fra Swap-filen.
S.W.G.T. — mengden RAM (MBytes) som ESXi ønsker å gi til VM fra Swap-filen (Swap Target).
Du kan også se mer detaljert informasjon om NUMA-topologien til VM gjennom ESXTOP. For å gjøre dette, velg feltene D, G:
LITEN – NUMA noder som VM er plassert på. Her kan du umiddelbart legge merke til brede vm, som ikke passer på én NUMA-node.
NRMEM – hvor mange megabyte minne VM tar fra den eksterne NUMA-noden.
NLMEM – hvor mange megabyte minne VM tar fra den lokale NUMA-noden.
N%L – prosentandel av VM-minne på den lokale NUMA-noden (hvis mindre enn 80 %, kan det oppstå ytelsesproblemer).
Minne på hypervisoren
Hvis CPU-tellere for en hypervisor vanligvis ikke er av spesiell interesse, er situasjonen den motsatte med minne. Høy minnebruk på en VM indikerer ikke alltid et ytelsesproblem, men høy minnebruk på en hypervisor utløser minnebehandlingsteknikker og forårsaker problemer med VM-ytelsen. Du må overvåke vertsminnebruksalarmer og forhindre at VM-er kommer inn i Swap.
Opphev bytte
Hvis en VM blir fanget i Swap, reduseres ytelsen kraftig. Spor av ballonger og komprimering forsvinner raskt etter at ledig RAM vises på verten, men den virtuelle maskinen har ikke hastverk med å returnere fra Swap til serverens RAM.
Før ESXi 6.0 var den eneste pålitelige og raske måten å fjerne en VM fra Swap på å starte på nytt (mer presist, slå av/på beholderen). Fra og med ESXi 6.0, selv om det ikke er helt offisielt, har det dukket opp en fungerende og pålitelig måte å fjerne en VM fra Swap. På en av konferansene kunne jeg snakke med en av VMware-ingeniørene som var ansvarlige for CPU Scheduler. Han bekreftet at metoden er ganske fungerende og sikker. Etter vår erfaring var det heller ingen problemer med det.
De faktiske kommandoene for å fjerne en VM fra Swap Duncan Epping. Jeg vil ikke gjenta den detaljerte beskrivelsen, jeg vil bare gi et eksempel på bruken. Som du kan se på skjermbildet, forsvinner Swap på VM en tid etter å ha utført den angitte kommandoen.
Tips for å administrere RAM på ESXi
Til slutt, her er noen tips som vil hjelpe deg å unngå problemer med VM-ytelse på grunn av RAM:
- Unngå overabonnement av RAM i produktive klynger. Det er tilrådelig å alltid ha ~20-30% ledig minne i klyngen slik at DRS (og administratoren) har plass til å manøvrere og VM-er ikke går til Swap under migrering. Ikke glem marginen for feiltoleranse. Det er ubehagelig når, når en server svikter og VM startes på nytt med HA, noen av maskinene også går til Swap.
- I svært konsoliderte infrastrukturer, prøv å IKKE lage VM-er med minne større enn halvparten av vertsminnet. Dette vil igjen hjelpe DRS med å distribuere virtuelle maskiner på tvers av klyngeservere uten problemer. Denne regelen er selvfølgelig ikke universell :).
- Se opp for vertsminnebruksalarm.
- Ikke glem å installere VMware Tools på VM-en og ikke slå av Ballooning.
- Vurder å aktivere Inter-VM TPS og deaktivere store sider i VDI- og testmiljøer.
- Hvis den virtuelle maskinen opplever ytelsesproblemer, sjekk om den bruker minne fra en ekstern NUMA-node.
- Fjern VM-er fra Swap så raskt som mulig! Blant annet, hvis VM er i Swap, lider lagringssystemet av åpenbare årsaker.
Det er alt for meg om RAM. Nedenfor er relaterte artikler for de som ønsker å gå dypere. Den neste artikkelen vil være dedikert til Storaj.
Nyttige lenker
Kilde: www.habr.com