Virtualization memory management: deel I

Gewild, gevraagd en handig bij iedere hypervisor: memory oversubscribe. Tot voor kort kon enkel VMware met ESX dit aanbieden. Het is nochtans zeer handig, want bij het virtualiseren op bestaande servers zal de eerste investering nogal snel naar extra RAM-geheugen gaan. Toch zit er verandering aan te komen. Tijd voor een diepgaand overzicht in enkele artikels.

Met dit artikel vliegen we er meteen in met de marktleider: VMware ESX. Wie denkt op de hoogte te zijn, kan bedrogen uitkomen, want met ESX 4.1 zijn er behoorlijk wat features bijgekomen, niet in het minst op het gebied van performance, stroombesparing en memorymanagement.

Wat commerciële producten betreft, is VMware ESX de enige die memory-oversubscription toelaat. Tot nu toe kon dit dankzij drie interessante oplossingen. Met ESX 4.1 is daar zelfs een vierde toepassing bijgekomen.

Transparant page sharing
Dit eerste artikel behandelt de interessantste: transparant page sharing (TPS).

Fysiek geheugen wordt onderverdeeld in zogenaamde memorypages, standaard 4 KB groot. De VMware hypervisor ESX zal deze pages onderling vergelijken en indien twee fysieke pages aan elkaar gelijk zijn, zal hij de virtuele pages linken op dezelfde fysieke page, waardoor deze eerste vrijkomt.

Dit gebeurt op de laagst mogelijke laag, dus over verschillende virtuele machines heen (onafhankelijk welke familie) en zelfs binnen één virtuele machine (VM). Dus zelfs met slechts één VM kan TPS al zijn nut bewijzen.

Transparant Page Sharing verklaard

Indien een VM dan wenst te schrijven naar deze page zal ESX de link verbreken en een nieuwe memorypage gebruiken. Deze Copy-on-Write-actie betekent evenveel overhead in vergelijking met wegschrijven naar een non-shared page.

We spreken dus over low-level, physical scanning op basis van hashwaarden, en om de performance niet nadelig te beïnvloeden gaat dit relatief traag. Standaard 60min/VM, maar met behulp van Mem.ShareScanTime kan dit aangepast worden.

Veel pages zijn zeroed out. Dit betekent dat het besturingssysteem ze gevuld heeft met nullen en dus klaar houdt om te gebruiken. Ze zijn echter niet in gebruik. Dit zijn dus uitstekende kandidaten voor TPS.

Door het trage scannen worden naast de zeropages echter weinig andere pages gedeeld. Voor VM’s die zeer frequent hun geheugen gebruiken, zal TPS veel minder indrukwekkend zijn.

In esxtop kunnen we duidelijk zien hoe de verhouding zero-pages/shared-pages is voor bepaalde VM’s. In bovenstaand voorbeeld zien we vier identieke Windows-VM’s die normaal gezien uitstekende kandidaten zijn voor TPS.

Objectief blijven
Er is veel vraag naar de performance-impact van TPS, maar deze valt zeer sterk mee, in sommige gevallen is het zelfs zo dat TPS een prestatievoordeel biedt. De memoryfootprint van een VM wordt er kleiner door, waardoor deze beter past binnen de CPU-cache.

In andere gevallen kan dan weer een licht negatieve impact worden waargenomen. Dit is meer specifiek zo bij Java-applicaties, JVM voegt namelijk een derde laag toe van geheugenbeheer. Doordat deze zeer frequent wijzigingen in zijn eigen memorypages aanbrengt, kan er een negatieve impact zijn.

(bron: Gabe’s Virtual World)

Een tweede reden tot bezorgdheid is het gebruik van recente V-MMU-compatibele CPU’s (AMD RVI/Intel EPT) in combinatie met large pages. In plaats van 4 KB is een memorypage hierdoor 2 MB. Dit maakt het aanzienlijk moeilijker om een hashwaarde te berekenen en een ‘match’ te vinden tussen twee pages. Indien geheugen echt dreigt op te raken op de fysieke machine zal ESX handmatig de large pages in kleinere stukken breken om aan TPS te kunnen doen.

Als we daar het gebruik van recente V-MMU-compatibele CPU’s (AMD RVI/Intel EPT) bijnemen, kan het erger worden. Deze oplossingen maken namelijk gebruik van een extra kolom in hun TLB-tabel om VM’S rechtstreeks aan geheugenpages te koppelen. Large pages helpen om deze tabel goed te kunnen gebruiken, maar als ESX deze pages terug uit elkaar trekt, zal dit contraproductief werken voor hardware memory management.

Indien met recente CPU’s wordt gewerkt, is het een best practice om large pages niet aan te zetten.

In een volgend artikel bespreken we de overige oplossingen.