VMware : Mécanisme mémoire ESXi

Nous dépoussiérons un sujet largement abordé mais malheureusement manquants à notre blog mais aussi pour compléter notre Deep Dive sur la gestion RAM ESXi

On va donc essayer de vous faire un condensé d’informations sur les mécanismes d’optimisations de RAM.

Les mécanismes de récupérations de RAM s’exécutent séquentiellement, selon l’état de l’ESXi (article explicatif prochainement)

1. TPS : Transparent Sharing
2. Ballooning
3. Compression
4. Swap

Page mémoire

La mémoire vivre est divisée en une multitude de petit bloc allouable. Ainsi une VM qui exécute un processus en mémoire aura allouée une page mémoire physique de l’ESXi

Une page peut être de différentes tailles, selon l’OS et l’application sollicitant la RAM

• Petite page : 4Kb (OS 32 bits, application non memory-vore)
• Large pages : 2Mb (OS 64 Bit, Base de données SQL, Oracle,…)

Overcommitment :

Donner plus de mémoire virtuelle à l’ensemble des VMs que l’ESXi peut avoir en mémoire physique

Transparent Page Sharing

TPS est le mécanisme VMware qui permet de mutualiser les pages mémoires générées par les VMs sur le même ESX.

Si plusieurs OS similaires tournent sur le même Host, il est très probable que les VMs aient de nombreuses empreintes mémoires identiques. Au lieu de multiplier les pages mémoires, TPS les scans toutes les 60 secondes et il les fait pointer vers une unique sur la RAM Hardware (Dé duplication de mémoire).

Le TPS n’est actif que sur les pages mémoires standard (4KB)

Les Larges Pages (2 MB) ne peuvent utiliser cette fonctionnalité 

Ballooning

Le ballooning est une fonctionnalité gérée par le pilote vmmemctl, installé avec les VMware Tools.

• Une VM a besoin d’avantage de mémoire physique
• La VM lance un appel au Vmkernel (Noyau de l’ESXi)
• Le VMkernel demande à toutes les VMs (équipées des Tools) d’allouer une partie de leur mémoire non consommée (mais réservée) au pilote vmmemctl
• Le pilote verrouille la mémoire demandée, signale au VMkernel que ces emplacements sont disponibles
• Le VMkernel redistribue la mémoire à la VM qui a besoin de mémoire
• Le pilote vmmemctl peut réserver au maximum 65% de la mémoire allouée.

Compression :

Si le TPS & Balloning n’ont pas réussi à libérer assez de mémoire, le VMkernel se met à scanner les pages zippable. Si une page peut être compressée à plus de 50% elle sera zippée.
Ce mécanisme est mis juste avant le SWAP car il est plus rapide de zipper – dézipper une page mémoire en RAM, que de venir la récupérer sur un disque mécanique.

Swapping :

Si tous les mécanismes précédents n’ont pas permis de libérer assez de mémoire alors l’ESXi se met à swapper, c’est-à-dire à copier les pages mémoires sur disque et la c’est la CATA coté perf

Pour observer les différents états RAM :

Dans les graphes de performances sous le client vSphere :

Petite légende :

• Shared => TPS
• Swap Used => la métrique SWAP EXi
• Swap IN => Quantité de mémoire sortie du Swap (De Disque vers RAM)
• Swap OUT => Quantité de mémoire Swappé (De la RAM vers Disque)
• Active : Mémoire réellement utilisé par le vMkernel pour faire tourner le Workload
• Granted : somme des mémoires VMs configurées
• Consumed : Toutes les pages mémoires touchés (Très souvent identique à Granted)

Sous ESXTOP

Esxtop => Touche « m »

• PMEM : Mémoire physique
• PSHARE : Transparent Page Sharing
• SWAP : .SWAP => Idéalement à 0
• ZIP : Compression idéalement à 0
• MEMCTL : Ballooning idéalement à 0

Pour aller plus loin