In dit artikel zullen we het hebben over de prestatiemeteritems van RAM (Random Access Memory) in vSphere.
Het lijkt erop dat met het geheugen alles duidelijker is dan met de processor: als een VM prestatieproblemen heeft, is het moeilijk om ze niet op te merken. Maar als ze verschijnen, is het veel moeilijker om ermee om te gaan. Maar de eerste dingen eerst.
Een beetje theorie
Het RAM van virtuele machines wordt gehaald uit het geheugen van de server waarop de VM's draaien. Het is vrij duidelijk :). Als het RAM-geheugen van de server niet genoeg is voor iedereen, begint ESXi geheugenterugwinningstechnieken te gebruiken om het gebruik van RAM te optimaliseren. Anders zouden VM-besturingssystemen crashen met RAM-toegangsfouten.
Welke technieken ESXi moet gebruiken, hangt af van de belasting van het RAM-geheugen:
Geheugenstatus
grens
acties
Hoge
400% van minGratis
Na het bereiken van de bovengrens worden grote geheugenpagina's opgesplitst in kleine pagina's (TPS werkt in de standaardmodus).
Clear
100% van minGratis
Grote geheugenpagina's worden opgedeeld in kleine, TPS wordt gedwongen te werken.
Soft /Pastel
64% van minGratis
TPS + Ballon
Hard
32% van minGratis
TPS + Comprimeren + Wisselen
Laag
16% van minGratis
Comprimeren + verwisselen + blokkeren
minFree is het RAM-geheugen dat nodig is om de hypervisor te laten werken.
Vóór ESXi 4.1 was minFree standaard vast - 6% van het RAM-geheugen van de server (het percentage kon worden gewijzigd via de Mem.MinFreePct-optie op ESXi). In latere versies werd, vanwege de toename van het geheugen op servers, minFree berekend op basis van de hoeveelheid hostgeheugen en niet als een vast percentage.
De minFree (standaard) waarde wordt als volgt berekend:
Percentage geheugen gereserveerd voor minFree
Geheugen bereik
6%
0-4GB
4%
4-12GB
2%
12-28GB
1%
Resterend geheugen
Voor een server met 128 GB RAM zou de MinFree-waarde bijvoorbeeld zijn:
Min Vrij = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
De werkelijke waarde kan enkele honderden MB verschillen, dit is afhankelijk van de server en het RAM-geheugen.
Percentage geheugen gereserveerd voor minFree
Geheugen bereik
Waarde voor 128 GB
6%
0-4GB
245,76 MB
4%
4-12GB
327,68 MB
2%
12-28GB
327,68 MB
1%
Resterend geheugen (100 GB)
1024 MB
Gewoonlijk kan voor productieve stands alleen de hoge status als normaal worden beschouwd. Voor test- en ontwikkelingsbanken kunnen Clear/Soft-statussen acceptabel zijn. Als de RAM op de host minder dan 64% MinFree is, hebben de VM's die erop draaien zeker prestatieproblemen.
In elke status worden bepaalde geheugenterugwinningstechnieken toegepast, te beginnen met TPS, wat praktisch geen invloed heeft op de prestaties van de VM, en eindigend met Swapping. Ik zal je meer over ze vertellen.
Transparante paginadeling (TPS). TPS is grofweg deduplicatie van geheugenpagina's van virtuele machines op een server.
ESXi zoekt naar identieke pagina's van het RAM van de virtuele machine door de hash-som van de pagina's te tellen en te vergelijken, en verwijdert dubbele pagina's en vervangt ze door koppelingen naar dezelfde pagina in het fysieke geheugen van de server. Als gevolg hiervan wordt het fysieke geheugenverbruik verminderd en kan enige geheugenoverbelasting worden bereikt met weinig of geen prestatieverlies.
Dit mechanisme werkt alleen voor 4 KB geheugenpagina's (kleine pagina's). De hypervisor probeert niet eens pagina's van 2 MB (grote pagina's) te ontdubbelen: de kans om identieke pagina's van dit formaat te vinden is niet groot.
ESXi wijst standaard geheugen toe aan grote pagina's. Het opsplitsen van grote pagina's in kleine pagina's begint wanneer de statusdrempel Hoog wordt bereikt en wordt geforceerd wanneer de status Clear wordt bereikt (zie de hypervisorstatustabel).
Als u wilt dat TPS begint te werken zonder te wachten tot het host-RAM vol is, moet u in Geavanceerde opties ESXi de waarde instellen "Mem.AllocGuestLargePage" tot 0 (standaard 1). Dan wordt de toewijzing van grote geheugenpagina's voor virtuele machines uitgeschakeld.
Sinds december 2014 is TPS tussen VM's in alle releases van ESXi standaard uitgeschakeld, omdat er een kwetsbaarheid is gevonden die in theorie toegang van de ene VM tot het RAM-geheugen van een andere VM mogelijk maakt. Details hier. Ik ben geen informatie tegengekomen over de praktische implementatie van het misbruiken van de TPS-kwetsbaarheid.
TPS-beleid beheerd via geavanceerde optie "Mem.ShareForceSalting" op ESXi:
0 - Inter-VM TPS. TPS werkt voor pagina's van verschillende VM's;
1 – TPS voor VM met dezelfde "sched.mem.pshare.salt"-waarde in VMX;
2 (standaard) - Intra-VM TPS. TPS werkt voor pagina's binnen de VM.
Het is absoluut logisch om grote pagina's uit te schakelen en Inter-VM TPS op testbanken in te schakelen. Het kan ook worden gebruikt voor stands met een groot aantal van hetzelfde type VM. Op stands met VDI kan de besparing in fysiek geheugen bijvoorbeeld oplopen tot tientallen procenten.
geheugen ballonvaren. Ballonvaren is niet meer zo'n onschuldige en transparante techniek voor het VM-besturingssysteem als TPS. Maar met de juiste toepassing kun je leven en zelfs werken met ballonvaren.
Samen met Vmware Tools wordt een speciaal stuurprogramma genaamd Balloon Driver (ook bekend als vmmemctl) op de VM geïnstalleerd. Wanneer de hypervisor geen fysiek geheugen meer heeft en in de Soft-status komt, vraagt ESXi de VM om ongebruikt RAM terug te vorderen via deze Balloon Driver. De driver werkt op zijn beurt op het niveau van het besturingssysteem en vraagt daar vrij geheugen van op. De hypervisor ziet welke pagina's fysiek geheugen de Balloon Driver in beslag heeft genomen, haalt het geheugen van de virtuele machine en geeft het terug aan de host. Er zijn geen problemen met de werking van het besturingssysteem, aangezien op besturingssysteemniveau het geheugen wordt ingenomen door de Balloon Driver. Standaard kan Balloon Driver tot 65% van het VM-geheugen in beslag nemen.
Als VMware Tools niet op de VM is geïnstalleerd of Ballooning is uitgeschakeld (ik raad het niet aan, maar er zijn :) schakelt de hypervisor onmiddellijk over op strengere geheugenverwijderingstechnieken. Conclusie: zorg ervoor dat VMware Tools op de VM staan.
De werking van Balloon Driver kan worden gecontroleerd vanuit het besturingssysteem via VMware Tools.
geheugen compressie. Deze techniek wordt gebruikt wanneer ESXi de harde status bereikt. Zoals de naam al aangeeft, probeert ESXi een pagina van 4 KB RAM te verkleinen tot 2 KB en zo wat ruimte vrij te maken in het fysieke geheugen van de server. Deze techniek vergroot de toegangstijd tot de inhoud van de VM RAM-pagina's aanzienlijk, aangezien de pagina eerst moet worden gedecomprimeerd. Soms kunnen niet alle pagina's worden gecomprimeerd en duurt het proces zelf even. Daarom is deze techniek in de praktijk niet erg effectief.
geheugen wisselen. Na een korte geheugencompressiefase zal ESXi bijna onvermijdelijk (als de VM's niet zijn vertrokken naar andere hosts of zijn uitgeschakeld) overschakelen naar Swapping. En als er heel weinig geheugen over is (Low state), dan stopt de hypervisor ook met het toewijzen van geheugenpagina's aan de VM, wat problemen kan veroorzaken in het guest OS van de VM.
Hier is hoe Swapping werkt. Wanneer u een virtuele machine inschakelt, wordt er een bestand met de extensie .vswp voor gemaakt. Het is even groot als het niet-gereserveerde RAM van de VM: het is het verschil tussen geconfigureerd en gereserveerd geheugen. Wanneer Swapping actief is, ontlaadt ESXi geheugenpagina's van virtuele machines in dit bestand en begint ermee te werken in plaats van met het fysieke geheugen van de server. Natuurlijk is zo'n "operatief" geheugen verschillende ordes van grootte langzamer dan het echte, zelfs als .vswp op snelle opslag ligt.
In tegenstelling tot Ballooning, wanneer ongebruikte pagina's van de VM worden gehaald, kunnen met Swapping pagina's die actief worden gebruikt door het besturingssysteem of applicaties binnen de VM naar schijf worden verplaatst. Als gevolg hiervan dalen de prestaties van de VM tot het punt van bevriezen. De VM werkt formeel en kan in ieder geval correct worden uitgeschakeld vanuit het besturingssysteem. Als je geduld hebt 😉
Als de VM's naar Swap zijn gegaan, is dit een abnormale situatie, die indien mogelijk het beste kan worden vermeden.
Prestatie meter items voor het belangrijkste VM-geheugen
Zo kwamen we bij het hoofdpunt. Om de status van het geheugen in de virtuele machine te bewaken, zijn er de volgende tellers:
Actief — toont de hoeveelheid RAM (KB) waartoe de VM toegang heeft gekregen in de vorige meetperiode.
Gebruik - hetzelfde als Actief, maar als een percentage van het geconfigureerde RAM-geheugen van de VM. Berekend met de volgende formule: actieve ÷ virtuele machine geconfigureerde geheugengrootte.
respectievelijk High Usage en Active zijn niet altijd een indicator van VM-prestatieproblemen. Als de VM agressief geheugen gebruikt (er tenminste toegang toe krijgt), betekent dit niet dat er onvoldoende geheugen is. Het is eerder een gelegenheid om te zien wat er in het besturingssysteem gebeurt.
Er is een standaard geheugengebruiksalarm voor VM's:
Gedeelde - de hoeveelheid VM RAM die is ontdubbeld met behulp van TPS (binnen de VM of tussen VM's).
Toegegeven - de hoeveelheid fysiek hostgeheugen (KB) die aan de VM is gegeven. Inclusief gedeeld.
Consumed (Toegekend - Gedeeld) - de hoeveelheid fysiek geheugen (KB) die de virtuele machine van de host verbruikt. Exclusief gedeeld.
Als een deel van het VM-geheugen niet uit het fysieke geheugen van de host wordt gegeven, maar uit het wisselbestand, of als het geheugen via de Balloon Driver van de VM wordt gehaald, wordt met dit bedrag geen rekening gehouden in Toegekend en Verbruikt.
Hoge toegekende en verbruikte waarden zijn volkomen normaal. Het besturingssysteem neemt geleidelijk geheugen van de hypervisor en geeft het niet terug. Na verloop van tijd benaderen de waarden van deze tellers in een actief draaiende VM de hoeveelheid geconfigureerd geheugen en blijven daar.
Nul — de hoeveelheid VM RAM (KB), die nullen bevat. Dergelijk geheugen wordt door de hypervisor als gratis beschouwd en kan aan andere virtuele machines worden gegeven. Nadat het gast-besturingssysteem iets naar nul geheugen heeft geschreven, gaat het naar Verbruikt en keert niet terug.
Gereserveerde overheadkosten — de hoeveelheid VM RAM, (KB) gereserveerd door de hypervisor voor VM-werking. Dit is een klein bedrag, maar het moet beschikbaar zijn op de host, anders start de VM niet.
Ballon — de hoeveelheid RAM (KB) die in beslag is genomen van de VM met behulp van de Balloon Driver.
Gecomprimeerde - de hoeveelheid RAM (KB) die is gecomprimeerd.
Verwisseld - de hoeveelheid RAM (KB) die, wegens gebrek aan fysiek geheugen op de server, naar schijf is verplaatst.
Tellers van ballon- en andere geheugenterugwinningstechnieken zijn nul.
Zo ziet de grafiek met geheugentellers eruit voor een normaal werkende VM met 150 GB RAM.
In de onderstaande grafiek heeft de VM duidelijke problemen. Onder de grafiek kunt u zien dat voor deze VM alle beschreven technieken voor het werken met RAM zijn gebruikt. Ballon voor deze VM is veel groter dan Verbruikt. In feite is de VM meer dood dan levend.
ESXTOP
Net als bij de CPU, als we snel de situatie op de host willen beoordelen, evenals de dynamiek ervan met een interval van maximaal 2 seconden, moeten we ESXTOP gebruiken.
Het ESXTOP-scherm van Memory wordt opgeroepen met de "m"-toets en ziet er als volgt uit (velden B, D, H, J, K, L, O zijn geselecteerd):
De volgende parameters zullen voor ons van belang zijn:
Mem overcommit gem - de gemiddelde waarde van het overabonnement van het geheugen op de host gedurende 1, 5 en 15 minuten. Als het boven nul is, dan is dit een gelegenheid om te zien wat er gebeurt, maar niet altijd een indicator van problemen.
In lijnen PMEM/MB и VMKMEM/MB - informatie over het fysieke geheugen van de server en het beschikbare geheugen voor VMkernel. Van het interessante hier kun je de waarde zien van minfree (in MB), de status van de host in het geheugen (in ons geval hoog).
In lijn NUMA/MB je kunt de distributie van RAM zien door NUMA-knooppunten (sockets). In dit voorbeeld is de verdeling ongelijk, wat in principe niet erg goed is.
Het volgende zijn algemene serverstatistieken over geheugenterugwinningstechnieken:
PSHARE/MB zijn TPS-statistieken;
WISSELEN/MB — Swap gebruiksstatistieken;
ZIP/MB — compressiestatistieken van geheugenpagina's;
MEMCTL/MB — Statistieken over het gebruik van ballonbestuurders.
Voor individuele VM's zijn we mogelijk geïnteresseerd in de volgende informatie. Ik heb de VM-namen verborgen om het publiek niet in verwarring te brengen :). Als de ESXTOP-metriek vergelijkbaar is met de teller in vSphere, geef ik de bijbehorende teller.
MEMSZ — de hoeveelheid geheugen die is geconfigureerd op de VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + onaangeroerd.
Grant — Toegekend aan MB.
TCHD — Actief in MB.
MCTL? - of Balloon Driver op de VM is geïnstalleerd.
MCTLSZ — Ballon naar MB.
MCTLGT — de hoeveelheid RAM (MB) die ESXi van de VM wil halen via Balloon Driver (Memctl Target).
MCTLMAX - de maximale hoeveelheid RAM (MB) die ESXi van de VM kan halen via de Balloon Driver.
SWCUR — de huidige hoeveelheid RAM (MB) die is toegewezen aan de VM vanuit het Swap-bestand.
SWGT - de hoeveelheid RAM (MB) die ESXi aan de VM wil geven vanuit het Swap-bestand (Swap Target).
Ook kunt u via ESXTOP meer gedetailleerde informatie zien over de NUMA-topologie van de VM. Selecteer hiervoor de velden D, G:
KLEIN – NUMA-knooppunten waarop de VM zich bevindt. Hier zie je meteen brede vm, die niet op één NUMA-knooppunt passen.
NRMEM - hoeveel megabytes geheugen de VM van het externe NUMA-knooppunt neemt.
NLMEM - hoeveel megabytes geheugen de VM van het lokale NUMA-knooppunt neemt.
N%L – percentage van het VM-geheugen op het lokale NUMA-knooppunt (indien minder dan 80% kunnen er prestatieproblemen optreden).
Geheugen op de hypervisor
Als de CPU-tellers voor de hypervisor meestal niet van bijzonder belang zijn, is de situatie omgekeerd met geheugen. Een hoog geheugengebruik op een VM duidt niet altijd op een prestatieprobleem, maar een hoog geheugengebruik op een hypervisor activeert technieken voor geheugenbeheer en veroorzaakt prestatieproblemen in de VM. Alarmen voor hostgeheugengebruik moeten worden bewaakt om te voorkomen dat de VM in Swap terechtkomt.
Ongedaan maken
Als een VM in Swap staat, zijn de prestaties sterk verminderd. Sporen van Ballooning en compressie verdwijnen snel nadat er gratis RAM op de host verschijnt, maar de virtuele machine heeft geen haast om terug te keren van Swap naar het server-RAM.
Vóór ESXi 6.0 was de enige betrouwbare en snelle manier om een VM uit Swap te halen, opnieuw op te starten (om preciezer te zijn, zet de container uit/aan). Beginnend met ESXi 6.0, hoewel niet helemaal officieel, is er een werkende en betrouwbare manier verschenen om een VM van Swap te verwijderen. Op een van de conferenties kon ik praten met een van de VMware-engineers die verantwoordelijk was voor CPU Scheduler. Hij bevestigde dat de methode goed werkt en veilig is. In onze ervaring waren er ook geen problemen mee.
De daadwerkelijke opdrachten voor het verwijderen van de VM uit de Swap Duncan Epping. Ik zal geen gedetailleerde beschrijving herhalen, maar een voorbeeld geven van het gebruik ervan. Zoals u in de schermafbeelding kunt zien, verdwijnt Swap enige tijd na het uitvoeren van de opgegeven opdrachten op de VM.
Tips voor ESXi-geheugenbeheer
Tot slot volgen hier enkele tips waarmee u problemen met VM-prestaties als gevolg van RAM kunt voorkomen:
- Vermijd geheugenoverbelasting in productieve clusters. Het is wenselijk om altijd ~20-30% vrij geheugen in het cluster te hebben, zodat DRS (en de beheerder) speelruimte hebben en VM's niet in Swap gaan tijdens de migratie. Vergeet ook de marge voor fouttolerantie niet. Het is onaangenaam wanneer, wanneer een server uitvalt en de VM opnieuw wordt opgestart met HA, sommige machines ook in Swap gaan.
- Probeer in sterk geconsolideerde infrastructuren GEEN VM's te maken met meer dan de helft van het hostgeheugen. Dit zal DRS opnieuw helpen om virtuele machines probleemloos over de clusterservers te verdelen. Deze regel is natuurlijk niet universeel :).
- Let op het alarm voor hostgeheugengebruik.
- Vergeet niet VMware Tools op de VM te installeren en Ballooning niet uit te schakelen.
- Overweeg Inter-VM TPS in te schakelen en Grote pagina's uit te schakelen in VDI- en testomgevingen.
- Als de VM prestatieproblemen ondervindt, controleert u of deze geheugen gebruikt van een extern NUMA-knooppunt.
- Haal uw VM zo snel mogelijk uit Swap! Als de VM zich onder andere in Swap bevindt, lijdt het opslagsysteem om voor de hand liggende redenen.
Dat is alles voor mij over RAM. Hieronder vindt u een gerelateerd artikel voor degenen die in de details willen duiken. Het volgende artikel zal gewijd zijn aan storadzh.
Nuttige links
Bron: www.habr.com