{"id":35292,"date":"2019-10-31T22:03:28","date_gmt":"2019-10-31T19:03:28","guid":{"rendered":"https:\/\/prohoster.info\/blog\/analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory\/"},"modified":"2019-10-31T22:03:28","modified_gmt":"2019-10-31T19:03:28","slug":"analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory","title":{"rendered":"Prestatieanalyse van VM's in VMware vSphere. Deel 2: Geheugen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Prestatieanalyse
\n
\nDeel 1. Over CPU<\/a><\/noindex><\/p>\n

In dit artikel bespreken we de prestatiestatistieken van het RAM-geheugen in vSphere.
\nBij 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. <\/a><\/noindex><\/p>\n

Een beetje theorie<\/h3>\n

\nHet 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. <\/p>\n

Welke technieken ESXi toepast, hangt af van de belasting van het RAM-geheugen:<\/p>\n

Geheugenstatus<\/b><\/p>\n

Grens<\/b><\/p>\n

Acties<\/b><\/p>\n

High<\/p>\n

400% van minFree<\/p>\n

Bij het bereiken van de bovengrens worden grote geheugenpagina's opgesplitst in kleine (TPS werkt in de standaardmodus).<\/p>\n

Wis<\/p>\n

100% van minFree<\/p>\n

Grote geheugenpagina's worden opgesplitst in kleine, TPS werkt geforceerd.<\/p>\n

Zacht<\/p>\n

64% van minFree<\/p>\n

TPS + Balloon<\/p>\n

Hard<\/p>\n

32% van minFree<\/p>\n

TPS + Compress + Swap<\/p>\n

Laag<\/p>\n

16% van minFree<\/p>\n

Compress + Swap + Block<\/p>\n

Bron<\/a><\/noindex> <\/p>\n

minFree is het RAM-geheugen dat nodig is voor de werking van de hypervisor. <\/p>\n

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. <\/p>\n

De standaardwaarde voor minFree wordt als volgt berekend:<\/p>\n

Percentage geheugen gereserveerd voor minFree<\/b><\/p>\n

Geheugenbereik<\/b><\/p>\n

6%<\/p>\n

0-4 GB<\/p>\n

4%<\/p>\n

4-12 GB<\/p>\n

2%<\/p>\n

12-28 GB<\/p>\n

1%<\/p>\n

Overgebleven geheugen<\/p>\n

Bron<\/a><\/noindex><\/p>\n

Bijvoorbeeld, voor een server met 128 GB RAM zou de waarde MinFree als volgt zijn:
\nMinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
\nDe werkelijke waarde kan enkele honderden MB verschillen, afhankelijk van de server en het RAM-geheugen.<\/p>\n

Percentage geheugen gereserveerd voor minFree<\/b><\/p>\n

Geheugenbereik<\/b><\/p>\n

Waarde voor 128 GB<\/b><\/p>\n

6%<\/p>\n

0-4 GB<\/p>\n

245,76 MB<\/p>\n

4%<\/p>\n

4-12 GB<\/p>\n

327,68 MB<\/p>\n

2%<\/p>\n

12-28 GB<\/p>\n

327,68 MB<\/p>\n

1%<\/p>\n

Overgebleven geheugen (100 GB)<\/p>\n

1024 MB<\/p>\n

\nVoor 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.<\/p>\n

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. <\/p>\n

Transparent Page Sharing (TPS).<\/b> TPS is, eenvoudig gezegd, deduplicatie van de geheugenpagina's van virtuele machines op de server.<\/p>\n

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.<\/p>\n

\"Prestatieanalyse
\nBron<\/a><\/noindex><\/p>\n

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.<\/p>\n

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).<\/p>\n

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 \u201cMem.AllocGuestLargePage\u201d<\/i> op 0 (standaard 1). Dan wordt de toewijzing van grote geheugenpagina's voor de virtuele machines uitgeschakeld.<\/p>\n

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 \u00e9\u00e9n virtuele machine mogelijk maakte. Details hier. Ik heb geen informatie over de praktische implementatie van de exploitatie van de TPS-kwetsbaarheid gezien.<\/p>\n

Het beleid voor TPS wordt gecontroleerd via de geavanceerde optie \u201cMem.ShareForceSalting\u201d<\/i> op ESXi:
\n0 \u2014 Inter-VM TPS. TPS werkt voor pagina's van verschillende virtuele machines;
\n1 \u2013 TPS voor virtuele machines met dezelfde waarde voor \u201csched.mem.pshare.salt\u201d in VMX;
\n2 (standaard) \u2013 Intra-VM TPS. TPS werkt voor pagina's binnen dezelfde virtuele machine.<\/p>\n

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. <\/p>\n

Geheugen Ballooning.<\/b> 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.<\/p>\n

Samen met de VMware Tools wordt er een speciale driver op de virtuele machine ge\u00efnstalleerd, 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.<\/p>\n

Als VMware Tools niet op de virtuele machine zijn ge\u00efnstalleerd of Ballooning is uitgeschakeld (niet aanbevolen, maar het is mogelijk), KB<\/a><\/noindex>:), gaat de hypervisor meteen over naar strengere technieken voor geheugenafname. Conclusie: zorg ervoor dat VMware Tools op de virtuele machine zijn ge\u00efnstalleerd.<\/p>\n

\"Prestatieanalyse
\nDe werking van de Balloon Driver kan vanuit het besturingssysteem worden gecontroleerd via VMware Tools.<\/i>.<\/p>\n

Geheugencompressie.<\/b> 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.<\/p>\n

Geheugenswapping.<\/b> 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.<\/p>\n

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.<\/p>\n

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 \ud83d\ude09<\/p>\n

Als de VM in Swap is gegaan, is dit een niet-standaard situatie die bij voorkeur moet worden vermeden.<\/p>\n

Belangrijkste prestatiestatistieken voor het geheugen van de virtuele machine<\/h3>\n

\nHier zijn we dan bij het belangrijkste. Voor het monitoren van de geheugentoestand in de VM zijn er de volgende statistieken:<\/p>\n

Actief<\/b> \u2014 toont het volume van het RAM (KB) dat de VM in de voorgaande meetperiode heeft benaderd.<\/p>\n

Gebruik<\/b> \u2014 hetzelfde als Active, maar in procenten van het geconfigureerde RAM van de VM. Wordt berekend met de volgende formule: active \u00f7 geconfigureerde geheugen grootte van de virtuele machine.
\nHoge 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.
\nEr is een standaard Alarm voor Geheugengebruik voor VM's:<\/p>\n

\"Prestatieanalyse
\n
\nGedeeld<\/b> \u2014 volume van het RAM van de VM, gededupliceerd met behulp van TPS (binnen de VM of tussen VM's).<\/p>\n

Granted<\/b> \u2014 volume van het fysieke geheugen van de host (KB) dat aan de VM is toegewezen. Inclusief Shared.<\/p>\n

Consumed<\/b> (Granted \u2014 Shared) \u2014 volume van het fysieke geheugen (KB) dat de VM van de host consumeert. Sluit Shared uit.<\/p>\n

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.
\nHoge 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.<\/p>\n

Nul<\/b> \u2014 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.<\/p>\n

Gereserveerde overhead<\/b> \u2014 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.<\/p>\n

Ballon<\/b> \u2014 het volume van het RAM-geheugen (Kbyte) dat van de VM is afgenomen met behulp van de Balloon Driver.<\/p>\n

Gecomprimeerd<\/b> \u2014 het volume van het RAM-geheugen (Kbyte) dat is gecomprimeerd.<\/p>\n

Swapped<\/b> \u2014 het volume van het RAM-geheugen (Kbyte) dat, door gebrek aan fysiek geheugen op de server, naar de schijf is verplaatst.
\nBallon en andere tellers voor geheugenreclametechnieken zijn gelijk aan nul.<\/p>\n

Zo ziet een grafiek eruit met de tellers van een normaal functionerende VM met 150 GB RAM.<\/p>\n

\"Prestatieanalyse
\n
\nIn 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. <\/p>\n

\"Prestatieanalyse
\n<\/p>\n

ESXTOP<\/h3>\n

\nNet 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.<\/p>\n

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):<\/p>\n

\"Prestatieanalyse
\n
\nDe volgende parameters zijn interessant voor ons: <\/p>\n

Gemiddelde geheugenovercommit<\/b> \u2014 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.<\/p>\n

In de regels PMEM\/MB<\/b> en VMKMEM\/MB<\/b> \u2014 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).<\/p>\n

In de regel NUMA\/MB<\/b> 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.<\/p>\n

Hier volgt de algemene statistiek van de server met betrekking tot geheugenhersteltechnieken:<\/p>\n

PSHARE\/MB<\/b> \u2014 dit is de TPS-statistiek;<\/p>\n

SWAP\/MB<\/b> \u2014 statistiek van het gebruik van Swap;<\/p>\n

ZIP\/MB<\/b> \u2014 statistiek van geheugencompressie;<\/p>\n

MEMCTL\/MB<\/b> \u2014 statistiek van het gebruik van de Balloon Driver.<\/p>\n

Voor afzonderlijke VM's kunnen we ge\u00efnteresseerd 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. <\/p>\n

MEMSZ<\/b> \u2014 de hoeveelheid geheugen die is geconfigureerd voor de VM (MB).
\nMEMSZ = GRANT + MCTLSZ + SWCUR + untouched.<\/p>\n

GRANT<\/b> \u2014 Granted in MB.<\/p>\n

TCHD<\/b> \u2014 Active in MB.<\/p>\n

MCTL?<\/b> \u2014 is de Balloon Driver op de VM ge\u00efnstalleerd.<\/p>\n

MCTLSZ<\/b> \u2014 Balloon in MB.<\/p>\n

MCTLGT<\/b> \u2014 de hoeveelheid RAM (MB) die ESXi van de VM wil onttrekken via de Balloon Driver (Memctl Target).<\/p>\n

MCTLMAX<\/b> \u2014 de maximale hoeveelheid RAM (MB) die ESXi van de VM kan onttrekken via de Balloon Driver.<\/p>\n

SWCUR<\/b> \u2014 de huidige hoeveelheid RAM (MB) die aan de VM is gegeven vanuit het Swap-bestand. <\/p>\n

SWGT<\/b> \u2014 de hoeveelheid RAM (MB) die ESXi aan de VM wil geven vanuit het Swap-bestand (Swap Target).<\/p>\n

Met ESXTOP kan ook meer gedetailleerde informatie over de NUMA-topologie van de VM worden bekeken. Hiervoor moeten de kolommen D,G worden geselecteerd:<\/p>\n

\"Prestatieanalyse
\n
\nNHN<\/b> \u2013 NUMA-knooppunten waarop de VM zich bevindt. Hier kunnen we meteen wijde VM's zien die niet op \u00e9\u00e9n NUMA-knooppunt passen.<\/p>\n

NRMEM<\/b> \u2013 hoeveel megabytes geheugen de VM van een extern NUMA-knooppunt neemt.<\/p>\n

NLMEM<\/b> \u2013 hoeveel megabytes geheugen de VM van een lokaal NUMA-knooppunt neemt.<\/p>\n

N%L<\/b> \u2013 percentage geheugen van de VM op het lokale NUMA-knooppunt (als dit minder dan 80% is, kunnen er prestatieproblemen optreden).<\/p>\n

Geheugen op de hypervisor<\/h3>\n

\nAls 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.<\/p>\n

\"Prestatieanalyse
\n
\n\"Prestatieanalyse
\n<\/p>\n

Unswap<\/h3>\n

\nAls 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.
\nTot 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\u00efntroduceerd 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.<\/p>\n

Eigenlijk de commando's om een VM uit Swap te halen beschreef<\/a><\/noindex> 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.<\/p>\n

\"Prestatieanalyse
\n<\/p>\n

Tips voor het beheer van RAM op ESXi<\/h3>\n

\nTot slot geef ik enkele tips die u kunnen helpen om prestatieproblemen van de VM als gevolg van RAM te vermijden:<\/p>\n