In dit artikel bespreken we de prestatiestatistieken van het RAM-geheugen in vSphere.
Bij RAM lijkt alles eenduidiger te zijn dan bij de CPU: als er prestatieproblemen op de VM optreden, zijn ze moeilijk te missen. Maar als ze optreden, is het veel moeilijker om ze op te lossen. Maar laten we alles op een rijtje zetten.
Een beetje theorie
Het RAM-geheugen van virtuele machines wordt gehaald uit het geheugen van de servers waarop de VMs draaien. Dat is vrij voor de hand liggend :). Als het servergeheugen niet voldoende is voor iedereen die dat wil, begint ESXi optimalisatietechnieken voor het geheugengebruik toe te passen (memory reclamation techniques). Anders zouden de besturingssystemen van de VMs met foutmeldingen over geheugenfouten crashen.
Welke technieken ESXi toepast, hangt af van de belasting van het RAM-geheugen:
Geheugenstatus
Grens
Acties
High
400% van minFree
Bij het bereiken van de bovengrens worden grote geheugenpagina's opgesplitst in kleine (TPS werkt in de standaardmodus).
Wis
100% van minFree
Grote geheugenpagina's worden opgesplitst in kleine, TPS werkt geforceerd.
Zacht
64% van minFree
TPS + Balloon
Hard
32% van minFree
TPS + Compress + Swap
Laag
16% van minFree
Compress + Swap + Block
minFree is het RAM-geheugen dat nodig is voor de werking van de hypervisor.
Tot en met ESXi 4.1 was minFree standaard vaststaand - 6% van de hoeveelheid RAM-geheugen van de server (het percentage kon worden gewijzigd via de optie Mem.MinFreePct in ESXi). In latere versies werd minFree vanwege de groei van het geheugengebruik op servers berekend op basis van de hoeveelheid hostgeheugen, en niet meer als een vast percentage.
De standaardwaarde voor minFree wordt als volgt berekend:
Percentage geheugen gereserveerd voor minFree
Geheugenbereik
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
Overgebleven geheugen
Bijvoorbeeld, voor een server met 128 GB RAM zou de waarde MinFree als volgt zijn:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
De werkelijke waarde kan enkele honderden MB verschillen, afhankelijk van de server en het RAM-geheugen.
Percentage geheugen gereserveerd voor minFree
Geheugenbereik
Waarde voor 128 GB
6%
0-4 GB
245,76 MB
4%
4-12 GB
327,68 MB
2%
12-28 GB
327,68 MB
1%
Overgebleven geheugen (100 GB)
1024 MB
Voor productieve omgevingen kan alleen de staat High normaal worden beschouwd. Voor test- en ontwikkelomgevingen zijn de staten Clear/Soft acceptabel. Als er minder dan 64% MinFree RAM op de host overblijft, zullen de virtuele machines die daarop draaien zeker prestatieproblemen ervaren.
In elke staat worden specifieke technieken voor geheugenrecuperatie toegepast, beginnend met TPS, dat praktisch geen invloed heeft op de prestaties van de virtuele machines, tot Swapping. Ik zal ze uitgebreider bespreken.
Transparent Page Sharing (TPS). TPS is, eenvoudig gezegd, deduplicatie van de geheugenpagina's van virtuele machines op de server.
ESXi zoekt naar gelijke geheugenpagina's van virtuele machines, rekent en vergelijkt de hash-waarde van de pagina's, en verwijdert dubbele pagina's, waarbij deze worden vervangen door verwijzingen naar dezelfde pagina in het fysieke geheugen van de server. Dit resulteert in een vermindering van het fysieke geheugengebruik en er kan een zekere overboeking van geheugen worden bereikt met praktisch geen prestatieverlies.
Dit mechanisme werkt alleen voor geheugenpagina's van 4 Kbyte (kleine pagina's). De hypervisor probeert grote pagina's van 2 Mbyte (grote pagina's) zelfs niet te dedupliceren: de kans om gelijke pagina's van deze grootte te vinden is niet groot.
Standaard wijst ESXi geheugen toe aan grote pagina's. Het splitsen van grote pagina's in kleine pagina's begint wanneer de High-status wordt bereikt en gebeurt gedwongen wanneer de Clear-status wordt bereikt (zie de tabel van hypervisorstatussen).
Als u echter wilt dat TPS begint te werken zonder te wachten tot het geheugen van de host vol is, moet u in de geavanceerde opties van ESXi de waarde instellen op “Mem.AllocGuestLargePage” op 0 (standaard 1). Dan wordt de toewijzing van grote geheugenpagina's voor de virtuele machines uitgeschakeld.
Sinds december 2014 is TPS tussen virtuele machines standaard uitgeschakeld in alle ESXi-releases, omdat er een kwetsbaarheid is ontdekt die theoretisch de toegang tot het geheugen van een andere virtuele machine vanuit één virtuele machine mogelijk maakte. Details hier. Ik heb geen informatie over de praktische implementatie van de exploitatie van de TPS-kwetsbaarheid gezien.
Het beleid voor TPS wordt gecontroleerd via de geavanceerde optie “Mem.ShareForceSalting” op ESXi:
0 — Inter-VM TPS. TPS werkt voor pagina's van verschillende virtuele machines;
1 – TPS voor virtuele machines met dezelfde waarde voor “sched.mem.pshare.salt” in VMX;
2 (standaard) – Intra-VM TPS. TPS werkt voor pagina's binnen dezelfde virtuele machine.
Het heeft beslist zin om grote pagina's uit te schakelen en Inter-VM TPS in te schakelen op testomgevingen. Dit kan ook worden gebruikt voor omgevingen met een groot aantal soortgelijke virtuele machines. Bijvoorbeeld, op VDI-omgevingen kan de besparing van fysieke geheugen wel tientallen procenten bedragen.
Geheugen Ballooning. Ballooning is al niet meer zo onschuldige en transparante techniek voor het besturingssysteem van de virtuele machine als TPS. Maar met een goede toepassing is het mogelijk om met Ballooning te werken en zelfs productief te zijn.
Samen met de VMware Tools wordt er een speciale driver op de virtuele machine geïnstalleerd, genaamd de Balloon Driver (ook wel vmmemctl). Wanneer de hypervisor niet genoeg fysiek geheugen heeft en in een Soft-toestand komt, vraagt ESXi de virtuele machine om ongebruikt RAM via deze Balloon Driver terug te geven. De driver werkt op het niveau van het besturingssysteem en vraagt vrij geheugen aan het besturingssysteem. De hypervisor ziet welke pagina's van fysiek geheugen de Balloon Driver heeft ingenomen, neemt geheugen van de virtuele machine en retourneert het aan de host. Er ontstaan geen problemen met het besturingssysteem, omdat op het niveau van het besturingssysteem het geheugen door de Balloon Driver wordt ingenomen. Standaard kan de Balloon Driver tot 65% van het geheugen van de virtuele machine terugnemen.
Als VMware Tools niet op de virtuele machine zijn geïnstalleerd of Ballooning is uitgeschakeld (niet aanbevolen, maar het is mogelijk), :), gaat de hypervisor meteen over naar strengere technieken voor geheugenafname. Conclusie: zorg ervoor dat VMware Tools op de virtuele machine zijn geïnstalleerd.
De werking van de Balloon Driver kan vanuit het besturingssysteem worden gecontroleerd via VMware Tools..
Geheugencompressie. Deze techniek wordt toegepast wanneer ESXi de Hard-toestand bereikt. Zoals de naam al aangeeft, probeert ESXi 4 KB-pagina's van RAM te comprimeren tot 2 KB en zo een beetje ruimte in het fysieke geheugen van de server vrij te maken. Deze techniek verhoogt aanzienlijk de toegangstijd tot de inhoud van pagina's in het RAM van de virtuele machine, omdat de pagina vooraf moet worden uitgewogen. Soms is het niet mogelijk om alle pagina's te comprimeren en het proces kost enige tijd. Daarom is deze techniek in de praktijk niet zeer effectief.
Geheugenswapping. Na een korte fase van Geheugencompressie gaat ESXi vrijwel onvermijdelijk (tenzij de virtuele machines naar andere hosts zijn verhuisd of zijn uitgeschakeld) over op Swapping. En als er echt niet veel geheugen meer over is (toestand Laag), stopt de hypervisor ook met het toewijzen van pagina's geheugen aan de virtuele machines, wat problemen kan veroorzaken in de gasten-besturingssystemen van de virtuele machines.
Zo werkt Swapping. Wanneer een virtuele machine (VM) wordt ingeschakeld, wordt er een bestand met de extensie .vswp aangemaakt. De grootte ervan komt overeen met het niet-gereserveerde RAM van de VM: dit is het verschil tussen de geconfigureerde en de gereserveerde geheugen. Tijdens Swapping dump ESXi pagina's van het geheugen van de virtuele machine naar dit bestand en begint het met dit bestand te werken in plaats van met het fysieke geheugen van de server. Uiteraard is dit soort 'RAM' vele malen trager dan echt geheugen, zelfs als de .vswp op snelle opslag staat.
In tegenstelling tot Ballooning, waarbij ongebruikte pagina's van de VM worden afgepakt, kunnen bij Swapping pagina's naar de schijf worden verplaatst die actief worden gebruikt door het besturingssysteem of applicaties binnen de VM. Dit resulteert in verminderde prestaties van de VM tot aan bevriezen. De VM blijft formeel functioneren en je kunt deze in ieder geval correct uitschakelen via het besturingssysteem. Wees geduldig 😉
Als de VM in Swap is gegaan, is dit een niet-standaard situatie die bij voorkeur moet worden vermeden.
Belangrijkste prestatiestatistieken voor het geheugen van de virtuele machine
Hier zijn we dan bij het belangrijkste. Voor het monitoren van de geheugentoestand in de VM zijn er de volgende statistieken:
Actief — toont het volume van het RAM (KB) dat de VM in de voorgaande meetperiode heeft benaderd.
Gebruik — hetzelfde als Active, maar in procenten van het geconfigureerde RAM van de VM. Wordt berekend met de volgende formule: active ÷ geconfigureerde geheugen grootte van de virtuele machine.
Hoge Usage en Active zijn niet altijd indicatoren voor prestatieproblemen van de VM. Als de VM agressief geheugen gebruikt (tenminste, er toegang toe krijgt), betekent dit niet dat er onvoldoende geheugen is. Sterker nog, dit is een reden om te kijken wat er in het besturingssysteem gebeurt.
Er is een standaard Alarm voor Geheugengebruik voor VM's:
Gedeeld — volume van het RAM van de VM, gededupliceerd met behulp van TPS (binnen de VM of tussen VM's).
Granted — volume van het fysieke geheugen van de host (KB) dat aan de VM is toegewezen. Inclusief Shared.
Consumed (Granted — Shared) — volume van het fysieke geheugen (KB) dat de VM van de host consumeert. Sluit Shared uit.
Als een deel van het geheugen van de VM niet uit het fysieke geheugen van de host wordt gehaald, maar uit het swap-bestand of als geheugen wordt afgenomen van de VM via de Balloon Driver, wordt dit volume niet meegenomen in Granted en Consumed.
Hoge waarden voor Granted en Consumed zijn volkomen normaal. Het besturingssysteem neemt geleidelijk geheugen van de hypervisor af en geeft het niet terug. Na verloop van tijd komen de waarden van deze tellers, bij een actief werkende VM, dichtbij de geconfigureerde hoeveelheid geheugen en blijven daar.
Nul — het volume van het RAM-geheugen van de VM (Kbyte), dat nullen bevat. Dit geheugen wordt door de hypervisor als vrij beschouwd en kan aan andere virtuele machines worden toegewezen. Nadat het gast-OS iets heeft geschreven naar het gewiste geheugen, gaat het naar Consumed en komt nooit meer terug.
Gereserveerde overhead — het volume van het RAM-geheugen van de VM (Kbyte) dat door de hypervisor is gereserveerd voor de werking van de VM. Het is een bescheiden volume, maar het moet beschikbaar zijn op de host, anders start de VM niet.
Ballon — het volume van het RAM-geheugen (Kbyte) dat van de VM is afgenomen met behulp van de Balloon Driver.
Gecomprimeerd — het volume van het RAM-geheugen (Kbyte) dat is gecomprimeerd.
Swapped — het volume van het RAM-geheugen (Kbyte) dat, door gebrek aan fysiek geheugen op de server, naar de schijf is verplaatst.
Ballon en andere tellers voor geheugenreclametechnieken zijn gelijk aan nul.
Zo ziet een grafiek eruit met de tellers van een normaal functionerende VM met 150 GB RAM.
In de onderstaande grafiek vertoont de VM duidelijke problemen. Onder de grafiek is te zien dat alle hierboven beschreven technieken voor geheugenbeheer zijn gebruikt. De Balloon voor deze VM is aanzienlijk groter dan Consumed. In feite is de VM eerder dood dan levend.
ESXTOP
Net als bij de CPU, als we snel de situatie op de host willen beoordelen en ook de dynamiek met een interval van 2 seconden willen bekijken, is het aan te raden om ESXTOP te gebruiken.
Het ESXTOP-scherm voor geheugen wordt opgeroepen met de toets "m" en ziet er als volgt uit (veld B,D,H,J,K,L,O zijn geselecteerd):
De volgende parameters zijn interessant voor ons:
Gemiddelde geheugenovercommit — het gemiddelde van de geheugenovercommit op de host over 1, 5 en 15 minuten. Als dit boven nul ligt, is het een reden om te kijken wat er aan de hand is, maar het is niet altijd een indicator van problemen.
In de regels PMEM/MB en VMKMEM/MB — informatie over het fysieke geheugen van de server en het geheugen dat beschikbaar is voor de VMkernel. Interessant om hier te zien is de waarde minfree (in MB), de status van de host met betrekking tot geheugen (in ons geval, hoog).
In de regel NUMA/MB je kunt de verdeling van het RAM-geheugen over de NUMA-nodes (socket) zien. In dit voorbeeld is de verdeling ongelijk, wat in principe niet ideaal is.
Hier volgt de algemene statistiek van de server met betrekking tot geheugenhersteltechnieken:
PSHARE/MB — dit is de TPS-statistiek;
SWAP/MB — statistiek van het gebruik van Swap;
ZIP/MB — statistiek van geheugencompressie;
MEMCTL/MB — statistiek van het gebruik van de Balloon Driver.
Voor afzonderlijke VM's kunnen we geïnteresseerd zijn in de volgende informatie. Ik heb de namen van de VM's verborgen om het publiek niet te verwarren:). Als de ESXTOP-metriek vergelijkbaar is met de teller in vSphere, geef ik de bijbehorende teller.
MEMSZ — de hoeveelheid geheugen die is geconfigureerd voor de VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.
GRANT — Granted in MB.
TCHD — Active in MB.
MCTL? — is de Balloon Driver op de VM geïnstalleerd.
MCTLSZ — Balloon in MB.
MCTLGT — de hoeveelheid RAM (MB) die ESXi van de VM wil onttrekken via de Balloon Driver (Memctl Target).
MCTLMAX — de maximale hoeveelheid RAM (MB) die ESXi van de VM kan onttrekken via de Balloon Driver.
SWCUR — de huidige hoeveelheid RAM (MB) die aan de VM is gegeven vanuit het Swap-bestand.
SWGT — de hoeveelheid RAM (MB) die ESXi aan de VM wil geven vanuit het Swap-bestand (Swap Target).
Met ESXTOP kan ook meer gedetailleerde informatie over de NUMA-topologie van de VM worden bekeken. Hiervoor moeten de kolommen D,G worden geselecteerd:
NHN – NUMA-knooppunten waarop de VM zich bevindt. Hier kunnen we meteen wijde VM's zien die niet op één NUMA-knooppunt passen.
NRMEM – hoeveel megabytes geheugen de VM van een extern NUMA-knooppunt neemt.
NLMEM – hoeveel megabytes geheugen de VM van een lokaal NUMA-knooppunt neemt.
N%L – percentage geheugen van de VM op het lokale NUMA-knooppunt (als dit minder dan 80% is, kunnen er prestatieproblemen optreden).
Geheugen op de hypervisor
Als CPU-tellers van de hypervisor meestal niet bijzonder interessant zijn, is de situatie met geheugen juist omgekeerd. Hoge geheugenbelasting op de VM wijst niet altijd op een prestatieprobleem, maar hoge geheugenbelasting op de hypervisor activeert juist geheugenbeheertechnieken en veroorzaakt prestatieproblemen voor de VM. We moeten de alarmen van Host Memory Usage in de gaten houden en voorkomen dat de VM in Swap terechtkomt.
Unswap
Als de VM in Swap terechtkomt, daalt de prestatie aanzienlijk. Sporen van Ballooning en compressie verdwijnen snel nadat er vrije RAM op de host verschijnt, maar de virtuele machine haast zich helemaal niet om terug te keren van Swap naar het RAM van de server.
Tot versie ESXi 6.0 was de enige betrouwbare en snelle manier om een VM uit Swap te krijgen het opnieuw opstarten (om precies te zijn, het uitschakelen/inschakelen van de container). Vanaf ESXi 6.0 is er echter een niet officieel, maar werkende en betrouwbare manier geïntroduceerd om een VM uit Swap te krijgen. Tijdens een van de conferenties had ik de kans om te praten met een van de ingenieurs van VMware die verantwoordelijk is voor de CPU Scheduler. Hij bevestigde dat deze methode volledig functioneel en veilig is. In onze ervaring zijn er ook geen problemen mee geconstateerd.
Eigenlijk de commando's om een VM uit Swap te halen Duncan Epping. Ik zal de gedetailleerde beschrijving niet herhalen, maar gewoon een voorbeeld van het gebruik geven. Zoals te zien is op de screenshot, verdwijnt Swap na enige tijd na het uitvoeren van het opgegeven commando van de VM.
Tips voor het beheer van RAM op ESXi
Tot slot geef ik enkele tips die u kunnen helpen om prestatieproblemen van de VM als gevolg van RAM te vermijden:
- Voorkom oversubscriberen van RAM in productieve clusters. Het is wenselijk om altijd ongeveer 20-30% vrije geheugen in het cluster te hebben, zodat DRS (en de administrator) ruimte heeft om te manoeuvreren en de VM's bij migratie niet naar Swap gaan. Vergeet ook de reservering voor fouttolerantie niet. Het is vervelend als, bij het uitvallen van een server en het opnieuw opstarten van de VM met HA, een deel van de machines ook nog eens naar Swap gaat.
- In infrastructuren met hoge consolidatie, probeer GEEN VM's te maken met meer geheugen dan de helft van het geheugen van de host. Dit zal DRS op nieuwe manieren helpen om de virtuele machines probleemloos over de servers van het cluster te verdelen. Deze regel is vanzelfsprekend niet universeel.
- Houd de Host Memory Usage Alarm in de gaten.
- Vergeet niet om VMware Tools op de VM te installeren en de Ballooning niet uit te schakelen.
- Overweeg om Inter-VM TPS in te schakelen en Large Pages uit te schakelen in VDI-omgevingen en testomgevingen.
- Als de VM prestatieproblemen heeft, controleer dan of deze geheugen van een externe NUMA-knooppunt gebruikt.
- Breng de VM zo snel mogelijk uit Swap! Naast alles, als de VM in Swap zit, lijdt de SAN, om voor de hand liggende redenen.
Dat was het voor nu over RAM. Hieronder artikelen over het onderwerp voor degenen die zich verder willen verdiepen in de details. Het volgende artikel zal gewijd zijn aan opslag.
Nuttige links
Bron: habr.com
