Dynamic Memory vs Memory Overcommit

De laatste tijd kom ik steeds vaker op internet posts tegen van mensen die denken
dat Memory Overcommit en Dynamic Memory hetzelfde doen, of zelfs hetzelfde zijn.
Dit is NIET zo! Deze post is bedoeld om dit te verduidelijken.

Onderliggende technologie
Memory ballooning kernel driver
clip_image002
Met deze techniek werken zowel Memory Overcommit als Dynamic Memory.
Ja, er komt dus wel iets overeen… want uiteindelijk zorgen ze er beide voor dat
de VM gebruik kan maken van meer geheugen.
Wat ballooning eigenlijk doet, is het aanbieden van meer geheugen addressen
aan de kernel van het OS binnen de VM. Je geeft de VM dus niet meer geheugen maar
geeft hem wel de mogelijkheid om gebruik te maken van meer geheugen.

Memory Overcommit
Er zijn meerdere technologieën om ervoor te zorgen dat een VM gebruik kan maken
van meer geheugen, zodra deze erom vraagt.
Een technologie om ervoor te zorgen dat een VM gebruik kan maken van meer
geheugen zodra deze erom vraagt, is Memory Overcommit.
Deze technologie maakt gebruik van een onderliggende technologie, genaamd “Idle
Memory Tax”, IMT afgekort. De eerste keer dat ik van deze term hoorde had ik geen
idee wat er werd bedoeld en ben dit toen gaan uitzoeken.
Als je een server hebt met 13GB RAM, waarvan 1 GB gereserveerd is voor
de host, dan kan er gebruik gemaakt worden van 12 GB RAM. Deze 12 GB RAM bestaat
uit (12*1024) 12.288 shares van geheugen.
Wat IMT doet, is een hogere waarde toekennen aan de vrije geheugen shares.
Dit kan omdat Memory Overcommit iedere geheugen share behandeld als een
losse resource… en ze uitwisselbaar maakt tussen meerdere VM’s.
Verder zijn er 3 punten waarmee Memory Overcommit werkt:

  1. Deel meer geheugen uit dan er daadwerkelijk in de host zit.
  2. Identificeer dezelfde geheugenblokken in meerdere VM’s d.m.v de hash.
  3. Comprimeer het geheugen van de host door deze geheugenblokken 1 keer op te
    slaan; de inhoud is toch hetzelfde.

Wat is het resultaat?
Wanneer een VM meer geheugen gaat vragen, zal Memory Overcommit een
andere VM zoeken die geheugen shares “over” heeft, met andere woorden
niet gebruikt. Deze geheugen shares worden vervolgens uitgedeeld aan de VM
die om meer geheugen vroeg.
Feitelijk wordt er 1 geheugen share aan 2 VM’s toegewezen. Hierdoor zullen
dus 2 VM’s dezelfde geheugenshares zien.

Een voorbeeld.
Stel dat je een host hebt met 6GB aan RAM, 4 VM’s met 1 GB aan RAM en Memory
Overcommit de mogelijkheid geeft om 1GB RAM aan iedere VM extra te geven.
Als alle 4 de VM’s het druk krijgen en om meer geheugen gaan vragen, zal Memory
Overcommit het geheugen opschalen.
Je krijgt dus (4VM * 1GB RAM) + (4VM * 1GB Memory Overcommit RAM) = 8GB RAM.
Dit kan niet, er zit namelijk maar 6GB in de host!
Vandaar de naam “overcommit”; je beloofd meer dan je waar kan maken.

De toegevoegde waarde?
Indien een VM meer geheugen nodig heeft en andere VM’s hebben geheugen over
dan kan de drukke VM gebruik maken van het vrije geheugen binnen de rustige VM’s.

Dynamic Memory
Een andere technologie om ervoor te zorgen dat een VM gebruik kan maken van meer
geheugen zodra deze erom vraagt, is Dynamic Memory.
Dynamic Memory ziet geheugen ook als een resource om uit te delen aan VM’s, echter
is hier het grote verschil dat het geheugen slechts aan 1 VM wordt gegeven.
Hoe dit kan? Iedere VM heeft een minimale hoeveelheid geheugen nodig.
Dit configureer je op iedere VM. Doordat ze standaard minder geheugen toegewezen
krijgen, blijft er veel geheugen over. Dit komt in een grote “pool”; al het geheugen
op de host wat vrij is (minus een kleine hoeveelheid gereserveerd voor de
host zelf) behoort tot deze “pool”.
Verder zijn er 3 punten waarmee Dynamic Memory werkt:

  1. Geef meer geheugen aan een VM indien deze erom vraagt.
  2. Het totale toegewezen geheugen kan nooit meer zijn als er fysiek in de host zit.
  3. De som van alle maximale toegewezen geheugen kan hoger zijn dan het fysieke
    geheugen in de host, echter zal er nooit meer als het fysieke toegewezen worden
    omdat ieder geheugenblok uniek is en maar 1 keer tegelijk gebruikt kan worden.

Wat is het resultaat?
Zodra een VM gaat vragen om meer geheugen, zal Dynamic Memory kijken of er
geheugen vrij is in de pool en indien het geval het geheugen toewijzen aan de VM.
Wanneer de VM het geheugen een tijdje niet gebruikt, zal Dynamic Memory het geheugen
weer terug vragen aan de VM en het weer toevoegen aan de “pool” zodat andere VM’s er
weer gebruik van kunnen maken.

Een voorbeeld.
Stel dat je een host hebt met 6GB aan RAM, 4 VM’s met allemaal 1GB geheugen waarbij
ze alle 4 een dynamisch geheugen toegewezen hebben gekregen van maximaal 2GB per stuk.
Ja, dit betekend een totaal van (4VM * 1GB) = 4GB! Dit betekend dat je 2GB aan
geheugen in de vrij inzetbare “pool” hebt. Je kan dus, in vergelijking met het voorbeeld
bij Memory Overcommit, 1 VM meer op deze machine kwijt… 1 VM van de 3 = 33% !!

De toegevoegde waarde?

De situatie die ik als voorbeeld heb genomen bij Dynamic Memory is standaard, niets
gedaan aan specifieke fine-tuning of iets dergelijks…
Indien je de omgeving gaat fine-tunen, is het mogelijk om in een situatie, bijvoorbeeld
in mijn demo-omgeving, het volgende tegen te komen:
clip_image003
Dit is dus een enorme verbetering qua dichtheid van je VM’s!

Wat maakt het verschil?
Het besturingsysteem binnen de VM vertrouwen.
Memory Overcommit vertrouwd de VM niet. Wat ik daarmee bedoel is dat er
wordt gekeken naar de informatie die beschikbaar is op de host; er wordt niet
binnen de VM gekeken.
Dynamic Memory kijkt daarentegen wel in de host, door middel van de Dynamic
Memory Virtual Service Consumer driver die geïnstalleerd wordt met de Integration
Services van Hyper-V. Deze laat Dynamic Memory weten wat de status is van het
geheugen binnen de VM. Geheugen erbij, geheugen eraf; door deze integratie
weet Dynamic Memory precies wat te doen wanneer het nodig is.
In simpele termen, Dynamic Memory krijgt de informatie rechtstreeks van de bron
en Memory Overcommit van een tussenpartij.

“Proven technology”.

Al meerdere jaren gebruiken bedrijven in hun productie omgevingen Memory
Overcommit en dit is dan dus ook een “proven technoloy”. Dynamic Memory is een
relatief nieuwe technologie en krijgt nu dus de kans om zichzelf te bewijzen.
Mijn inziens, omdat ik als sinds de beta van ServicePack 1 ermee werk, gaat dit lukken.

Second Level Paging
Deze onderliggende technologie wordt wel gebruikt door Memory Overcommit, maar
niet door Dynamic Memory. Om Second Level Paging te begrijpen moeten we het
concept van “paging” begrijpen. Als we virtualisatie nu nog even buiten beschouwing
laten, dan is paging het uitbreiden van het fysieke geheugen met virtueel
geheugen, wat feitelijk een page-file is op de harddisk. Indien het fysieke
geheugen “vol” is, dan kan er uitgeweken worden naar het virtuele geheugen.
Maar hoe zit het in gevirtualiseerde omgevingen? Want juist daar maken we gebruik
van Memory Overcommit of Dynamic Memory…
Als je een gevirtualiseerde omgeving schematisch tekent dan krijg je het volgende:
clip_image004
Indien de totale som van het extra geheugen hoger is dan het totale fysieke
geheugen in de host spreekt men over “oversubscription”.
Dit heeft echter als gevolg dat de VM’s zien dat het fysieke geheugen vol zit en dus
gaan swappen naar het virtuele geheugen op de disk.
Second Level Paging geeft de hypervisor de mogelijkheid om voor de VM’s het
swappen uit te voeren op de host. Dit is wel trager, en kan dus een negatief effect
hebben op de performance.
Ook ontstaat het risico dat er bepaalde geheugenblokken door Second Level Paging
geswapt worden richting de pagefile van de host, maar die om performance redenen
beter binnen de VM kunnen blijven. Omdat Memory Overcommit de host niet
vertrouwd zal hij niet zien wat die geheugenblokken zijn, dus kan hij ook niet
beoordelen welke wel en welke niet te gaan swappen.
Om geen performance verlies niet te riskeren maakt Dynamic Memory dan ook
geen gebruik van Second Level Paging; alle “swapping” van naar virtueel
geheugen vind zich plaats binnen de VM.
Zowel bij het gebruik van Memory Overcommit als bij Dynamic Memory wordt
geadviseerd de machines voldoende geheugen te geven om het “swappen” naar
de disk te voorkomen.
De reden? Omdat de performance van fysiek geheugen aanzienlijk hoger ligt als dat
van een harddisk.

Mijn conclusie

Welke van deze 2 technologieën het beste is, is nog niet zo eenvoudig te zeggen.
Mijn persoonlijke voorkeur lijkt me aan de hand van deze en mijn vorige posts
wel duidelijk; Dynamic Memory.
Beide technologieën bereiken hetzelfde indien je kijkt naar het feit dat je
een VM, indien nodig, dynamisch meer geheugen kan geven. Memory Overcommit
heeft het voordeel al langere tijd te bestaan en dat het een “proven technology” is
maar als nadeel dat het niet rechtstreeks in contact staat met de kernel van het OS
binnen de VM’s.
Ook is er bij het gebruik van Dynamic Memory niet het risico dat er geheugenblokken
geswapt worden richting de host, omdat er geen gebruik gemaakt wordt van Second
Level Paging; alle paging vind zich plaats binnen de VM.
Dynamic Memory richt op het efficienter gebruik maken van je resources
per datacenter+host in plaats van op het niveau van de host+VM, evenals hij wel
rechtstreeks in contact staat met de kernel van het OS binnen de VM. Wat ik echter
wel zie is dat het mogelijk is, door gebruik te maken van Dynamic Memory, je VM’s niet
meer in te richten op de pieken maar op de dalen. Uiteindelijk kun je meer VM’s kwijt op
minder hardware en je hosts die je daardoor vrij maakt uit kunt zetten.
Doordat Dynamic Memory het geheugen uit de “pool” kan verdelen over VM’s indien
dit nodig is, blijven de VM’s dan ook goede performance leveren… want met te weinig
resources (dus ook geheugen) gaat er performance verloren.

© Jeff Wouters Microsoft.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.