VMware : ESXi – Large Page OR NOT Large Page – Telle est la question ?

 

Prérequis à cette article :

 

 

Explication 

TPS est arrivé aux jours, ou les VMs avaient des OS principalement 32 bits avec des pages mémoires à 4kb (Rappel : TPS ne fonctionne pas avec les larges pages supérieures à 2MB)

C’était révolutionnaire car ceci permettait d’économiser sur de la production jusqu’à 20% de RAM et pour du VDI jusqu’à 50%.

Avant d’aborder le contexte d’aujourd’hui et les OS 64 bits, il est important de définir un des mécanismes de mappage mémoire, le TLB

 

TLB selon Wikipedia en 1 phrase 

Le translation lookaside buffer, ou TLB, est une mémoire cache du processeur utilisée par l’unité de gestion mémoire (MMU) dans le but d’accélérer la traduction des adresses virtuelles en adresses physiques.

En gros c’est le sommaire, la table d’adressage entre la mémoire virtuelle et la mémoire physique.

C’est un cache de taille très limitée, donc avec des pages mémoires à 4MB vous comprendrez que c’est plus rapide de la traverser.
Mais avec des pages mémoires à 4KB, la table est beaucoup plus importante donc plus coûteuse en cycle CPU afin de la traverser.

Exemple : VM de 2Go RAM

• 2048MB/4KB=512.000 => entrées pour pages à 4kb
• 2048MB/2.048MB =1000 => entrés pour pages à 2MB
• Ratio de 512

 

Avec les serveurs de plus en plus sizés en RAM, c’est naturellement que les éditeurs se redirigent vers des Larges Pages (2MB) car pour certaines instructions mémoire, c’est plus performant et aussi moins coûteux en cycle CPU dû au “sommaire” moins important.

Donc nos OS d’aujourd’hui fonctionnent majoritairement en page de 2MB mais cela n’arrange pas notre TPS et notre besoin d’Overcommit.

Vous pouvez alors complètement désactiver les Larges pages, mais cela risque de porter atteintes aux performances VM, via l’option “Mem.AllocGuestLargePage“

Descriptif VMware : ICI

Mem.AllocGuestLargePage

• Pour désactiver les Larges Pages => 0
• Pour activer les Larges Pages => 1

 

 

 

Large Page On Demand

Mais il existe une autre option qui est plus connu sous “Large Page On Demand”, qui permet d’allouer des Larges Pages exclusivement lorsque l’OS et plus précisent l’application en fera la demande.

Ainsi une bonne proportion des pages mémoires allouées seront de 4kb donc admissible au TPS.

Options : 

LPage.LPageAlwaysTryForNPT

• Pour désactiver les Larges Pages => 0
• Pour activer les Larges Pages => 1

 

 

 

 

 

Assez d’explication passons aux Tests

Serveur :

• Nutanix Supermicro NX-3060-G4
• 390 Go de RAM
• Intel Xeon E5-2660 v3 2 x 10 Coeurs à 2.6Ghz

 

 

Test 1

On va envoyer une grosse boite de VMs sur un ESXi.

Pour simuler un Workload de Production, on lance la création et démarrage de 300 VMs, merci au Nutanix Fast Clone pour cloner 300 VMs en quelques minutes (Honnêtement moins 10) :

• 100 x Windows 2012 (OS seul)
  Pour tester sans application 
• 100 x Windows 2012 + SQL server
  Avec une Application friand des Larges Pages
• 100 x Debian 7 32 Bits
  Ne travaillant qu’avec des Petites Pages (4KB)

 

On active le LPage.LPageAlwaysTryForNPT à 0

On démarre le tout, et tout de suite ce que l’on remarque c’est le CPU qui s’emballe. En effet comme vue ensemble le CPU est très sollicité pour les SCAN des pages mémoires

 
Niveau mémoire, au début qu’une infime partie Shared (Page de démarrage remplit de 0) est dedupliquée, puis on observe le Sharing qui commence à prendre sa place gentillement et gagner du terrain.

 

On le laisse tourner pour voir enfin une récupération effective au bout de plus d’une heure de Scan et dedup RAM.

 

 

Coté CPU la tempête passée, le CPU retrouve une consommation normale.

 

 

Résultat du Test 1 :

• Plus de 300 VMs de config différentes déployées.
• Plus de 225Go de RAM sauvée (et ça monte, ça monte)
• 0 SWAP, 0 compression – 0 Ballooning
• Memory Overcommit de 0.59 et avec 150Go de RAM de dispo on aurait pu pousser bien plus loin

 

 

Test 2 

On s’est amusé à déployer 1024 VMs Debian 32Bits (fonctionnant avec des pages de 4kb) de config 1vCPU et 2Go RAM

 

Résultat Test 2 :

• 157Go RAM sauvegardé via TPS
• 0 SWAP – 0 Compression – 0 Ballooning
• Overcommitment de malade à un ration de plus de 4 et avec encore un boulevard devant nous car 260Go de RAM sont disponible

 

 

 

Test 3 

On a voulu taper dans de la plus grosse VM, donc à cloné 201 vRA 7 appliance 64bits (VMware vRealize Automation). Et la on a le TPS qui monte qui monte.

VM : 1vCPU & 18Go RAM
Notre but était de saturer l’ESXi mais TPS fait trop bien son JOB.

Résultat Test 3 :

• 322Go RAM sauvegardé via TPS
• 0 SWAP – 0 Compression – 0 Ballooning 
• Overcommitment de malade à un ration de plus de 8, mais la sur allocation ne veut rien dire car ce sont des VM de 18Go de RAM configurées et elle ne consomme que 1.5Go)

 

 

 

 

 

On reprend l’expression de nos Sensei qui nous on inspiré à faire ces tests Hypervisor.fr

Moralité, TPS c’est bon, mangez-en !

 

 

 

 

Pour aller plus loin :