Sans autre tuning que le paramètre LPageAlwaysTryForNPT, TPS nous a permis de récupérer plus de 50% de RAM soit + de 12.5To sans impact sur le ressenti utilisateur (cliquez sur les graphs pour avoir le détail des compteurs) :

Merci qui ?

These issues are due to bug in large page promotion path on destination host during vMotion.

MAJ 22/10/2015 : Et encore des mecs qui confondent cloud et homelab…

All experiments run on a dual CPU blade server with two AMD Opteron 6272 CPUs (16 cores each) and 32 GB of RAM.

MAJ 26/02/2015 : Le patch pour la 5.0 vient de sortir, la boucle est bouclée.

Vous ne vous en êtes peut être pas rendu compte lors de votre dernière campagne de patching mais depuis mi-Octobre 2014, tout nouveau patch d’ESXi ajoute une fonctionnalité de salage pour TPS. Désactivée lors de son introduction mais bien destinée à être activée de force lors d’un patch ultérieur. Jusqu’à fin Janvier, seule la version 5.1 était concernée mais depuis le 27/01 la version 5.5 bénéficie aussi de cette nouvelle “feature”. La 5.0 est encore épargnée à ce jour.

As we noted earlier on Oct 16, Nov 24 and Dec 4, VMware has introduced new TPS (Transparent Page Sharing) management options. Today’s release of ESXi 5.5 U2d restricts TPS to individual VMs and disables inter-VM TPS by default unless an administrator chooses to re-enable it. Please see KB 2097593 for full details on the functionality.

Depuis l’annonce, beaucoup de bullshit. De nombreux blogeurs ont donné leur avis sur la question en omettant volontairement (aka je-suis-pas-un-expert-en-sécu) d’analyser les recherches qui ont abouti a cette rustine. Nous ne sommes pas expert en matière de sécurité non plus, par contre on ne va pas se gêner pour décortiquer les résultats de ces recherches et les critiquer. On commence par la kb 2080735 de VMware :

Published academic papers have demonstrated that by forcing a flush and reload of cache memory, it is possible to measure memory timings to try and determine an AES encryption key in use on another virtual machine running on the same physical processor of the host server if Transparent Page Sharing is enabled between the two virtual machines. This technique works only in a highly controlled system configured in a non-standard way that VMware believes would not be recreated in a production environment.

Even though VMware believes information being disclosed in real world conditions is unrealistic, out of an abundance of caution upcoming ESXi Update releases will no longer enable TPS between Virtual Machines by default

C’est pourtant clair mais VMware à quand même choisi de jouer la carte de la sécurité.

Une petit coup de Google nous a rapidement permis d’identifier les rapports de recherche à l’origine du mélodrame : Fine grain Cross-VM Attacks on Xen and VMware are possible! et Wait a minute! A fast, Cross-VM attack on AES dont les travaux semble basés sur un autre rapport datant de 2013 : FLUSH+RELOAD: a High Resolution, Low Noise, L3 Cache Side-Channel Attack

Extraits choisis du document de 2013 :

The technique uses the processor’s clflush instruction to evict the monitored memory locations from the cache, and then tests whether the data in these locations is back in the cache after allowing the victim program to execute a small number of instructions.

While copy-on-write protects shared pages from modifications, it is not fully transparent. The delay introduced when modifying a shared page can be detected by processes, leading to a potential information leak attack.

An important feature of the LLC in modern Intel processors is that it is an inclusive cache (NDLR : Et donc pas AMD). That is, the LLC contains copies of all of the data stored in the lower cache levels. Consequently, flushing or evicting data from the LLC also remove said data from all other cache levels of the processor. Our attack exploits this cache behaviour.

Retrieving data from memory or from cache levels closer to memory takes longer than retrieving it from cache levels closer to the core. This difference in timing has been exploited for side-channel attacks.

A round of attack consists of three phases. During the first phase, the monitored memory line is flushed from the cache hierarchy.

The spy, then, waits to allow the victim time to access the memory line before the third phase.

In the third phase, the spy reloads the memory line, measuring the time to load it. If during the wait phase the victim accesses the memory line, the line will be available in the cache and the reload operation will take a short time.

Maintenant qu’on en sait un peut plus sur la nature de l’attaque, voyons un peu les contraintes d’applications dans la vraie vie :

For a virtualised environment, the attacker needs access to a guest co-located on the same host as the victim guest. Techniques for achieving co-location are described by Ristenpart et al.
[...]
Identifying the OS and software version in co-resident guests has been dealt with in past research.

D’un coup de baguette magique, on se retrouve sur le même ESX avec le même GuestOS. Facile. On continue :

For the attack to work, the spy and the victim must execute on the same physical processor. For our testing, we set the processor affinity on the multi-processor system. However, in a real attack scenario the attack depends on the system scheduler.

Vous avez bien lu, la VM de l’attaquant doit résider sur le même processeur que la VM de la victime. Cache L3 oblige. Et c’est pas fini :

When performing the tests, the spy and the victim were the only load on the system. Such a scenario is not representative of a real system where multiple processes are running. We expect such load to create noise that will affect the quality of capture. Furthermore, for a load that includes multiple parallel instances of GnuPG, the spy will be unable to distinguish between memory access of each instance and will be unable to recover any data.

Donc, pour que l’attaque soit réalisable, il faut que la VM de l’attaquant se retrouve, avec la VM de la victime, seules sur le même socket du même ESX et avec le même GuestOS ! Et c’est toujours pas fini.

Extraits choisis du document sur l’attaque AES :

We know that VMware implements TPS with large pages (2 MB) or small pages (4 KB). We decided to use the later one, since it seems to be the default for most systems. Furthermore, as stated in [28], even if the large page sharing is selected, the VMM will still look for identical small pages to share.

Sachant que TPS ne supporte pas les large pages qui sont la configuration par défaut d’ESX depuis des années, non seulement ESX ne serait que partiellement vulnérable uniquement en cas d’overcommit important mais de plus le contexte initiale de l’étude est complètement faux.

Disabling the deduplication would make the attack impossible in the cloud however memory deduplication is highly performance beneficial, especially in cloud where multiple users share the same hardware. This is why we believe that the system designers should restrict the deduplication mechanism rather then completely disabling it.

Quel dilemme…

We not only performed the attack in native machine, but also in a cloud-like cross-VM scenario.

“cloud-like” et pourtant :

All experiments were performed on a machine featuring an Intel i5-3320M four core clocked at 3.2GHz.

Ironie du sort, un récent rapport de recherche décrit un nouveau type d’attaque sur le cache L3 en exploitant…les large pages !

S$A: A new deduplication free L3 cache side channel technique: We proposed a new side channel technique that is applied in the L3 cache and therefore can be applied in cross-core scenarios. The new side channel technique bases its methodology in the usage of huge size pages, which give extra information about the position that each memory location occupies in the L3 cache.

Prochaine étape : désactivation des large pages par défaut ou V2P en masse.

The relevance of these studies is highlighted by the prompt security update by VMware, making memory deduplication an opt-in feature that was formerly enabled by default.
[...]
We have disclosed our attack to the security teams of VMware, Amazon AWS and Citrix.

Mais revenons en au salting et à ses effets en cas d’overcommit. Sur un Dell R730 avec 256Go de RAM, nous nous sommes amusé à démarrer 512 VM SUSE 11 x64 1vcpu 2Go de vRAM avec des combinaisons de settings Mem.ShareForceSalting et Mem.AllocGuestLargePage différentes. Pour éviter que ça coince pendant le swapout, nous avons redirigé les vswp sur des SSD NVMe. On commence en mode défaut (Mem.ShareForceSalting=2 et Mem.AllocGuestLargePage=1) :

La courbe d’overhead (orange) permet de se rendre compte de la progression du démarrage des 512 VM. On remarque qu’au 3/4 du bootstorm le premier mécanisme de reclaim est la swap, viennent ensuite la compression, le ballooning et seulement après le sharing (principalement des zéros). Avec 23Go de swap et 43Go de zip, n’espérez pas des temps de réponses de folie même avec du SSD. On continue sans le salting (Mem.ShareForceSalting=0 et Mem.AllocGuestLargePage=1) :

Avec plus de 100Go de sharing et seulement 3,6Go de swap les effets de l’overcommit (3:1 quand même) sont presque imperceptibles dans ce scénario même si on regrette de constater que le swapping est encore le 1er mécanisme à se déclencher. Maintenant passons en full small pages (Mem.ShareForceSalting=0 et Mem.AllocGuestLargePage=0) :

Là on est au top, 200Go de sharing et un démarrage tout en douceur sans swap, compression ni balloon. Et pour finir, notre fameuse technique du Large Page on Demand (Mem.ShareForceSalting=0 Mem.AllocGuestLargePage=1 et LPage.LPageAlwaysTryForNPT=0) :

Même chose mais avec “seulement” 143Go de sharing, la différence étant vraisemblablement attribuée à des large pages.

Moralité, optez pour un régime sans sel !

In the cases where host memory is overcommitted, ESX may have to swap out pages. Since ESX will not swap out large pages, during host swapping, a large page will be broken into small pages.

Afin d’avoir une meilleure visibilité sur ce qui change au moment où nous avons activé le paramètre et lancé une vague de vmotion au sein du cluster pour l’appliquer, nous avons utilisé les mêmes compteurs que le “dashboard” Guest Memory (aka ResourcePoolQuickStats) pour en faire un rrd sous cacti (avec les même couleurs) :

Un gain immédiat de 20% de RAM sans consommation CPU supplémentaire ni augmentation manifeste de latence (dans notre cas) :

Et pour ceux qui se posent la question, dans ce cluster cumulant 1.5To de RAM attribuée à des VM Windows 2008 R2 et RHEL 6 x64, seulement 40Go de Large Pages sont allouées en moyenne.

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

ESX will not share large physical pages because:

The probability of finding two large pages that are identical is very low.
The overhead of performing a bit-by-bit comparison for a 2MB page is much higher than for a 4KB page.

Paradoxalement, c’est dans l’excellent Windows Internals que nous avons trouvé l’explication la plus synthétique à propos des large pages :

The primary advantage of large pages is speed of address translation for references to other data within the large page. This advantage exists because the first reference to any byte within a large page will cause the hardware’s translation look-aside buffer (TLB, described in a later section) to have in its cache the information necessary to translate references to any other byte within the large page. If small pages are used, more TLB entries are needed for the same range of virtual addresses, thus increasing recycling of entries as new virtual addresses require translation. This, in turn, means having to go back to the page table structures when references are made to virtual addresses outside the scope of a small page whose translation has been cached. The TLB is a very small cache, and thus large pages make better use of this limited resource.

On comprend donc aisément que sur des systèmes avec de plus en plus de RAM, les accès au TLB puissent être coûteux en CPU sans l’utilisation des large pages. Par contre, lorsqu’il n’y a plus de pages de 2Mo disponibles et parce que les large pages ne peuvent pas être swappées, ESX “casse” les large pages en small pages (dont le hash a déjà été computé) et TPS déduplique le tout :

Since ESX will not swap out large pages, during host swapping, a large page will be broken into small pages. ESX tries to share those small pages using the pre-generated hashes before they are swapped out.

Sur un système raisonnablement overcommité et sans tuning spécifique, l’ESX risque de ne pas “casser” et dedupliquer les pages suffisamment rapidement pour répondre à la demande de mémoire, ce qui peut engendrer une dégradation de performance (ballooning/zipping/swapping). A l’inverse, si le coût CPU est acceptable, le même système tuné pour ne faire que (ou presque que) des small pages n’aura pas cette problématique.

Ci dessous, la comparaison des stats mémoire d’un cluster (composé de serveurs à base d’Intel Nehalem) sans tuning spécifique et des stats de ce même cluster après avoir forcé l’utilisation des small pages sur les vm (workload comparable) :

La première chose qui frappe c’est le compteur “consumed” qui a diminué de moitié (le workload s’y prête bien dans ce cas puisqu’il s’agit d’une ferme de serveurs xenapp) grâce à TPS,  le compteur “shared” a en effet été multiplié par 10. Dans le cas présent, la consommation CPU a augmenté d’environ 15% lors du passage aux small pages.

Voici la commande powershell qui a permis de désactiver les large pages sur les vm (vm reboot ou “vmotion shake” pour la prise en compte) :

Get-View -ViewType VirtualMachine|?{!$_.Config.Template -and $_.Runtime.ConnectionState -eq "connected"}|?{!($_.Config.ExtraConfig|?{$_.Key -eq "monitor_control.disable_mmu_largepages"}|?{$_.value -match "true|1"})}|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{extraconfig=(New-Object Vmware.Vim.OptionValue -Property @{Key="monitor_control.disable_mmu_largepages";Value="1"})}))}

Il est également possible d’obtenir un résultat similaire en forçant la VMM a utiliser le mode mmu software :

C’est quasiment identique mais la grande classe c’est qu’en powershell on peut forcer le mode cpu auto et le mode mmu software de la VMM (impossible en GUI) :

Get-View -ViewType virtualmachine|?{!$_.Config.Template -and $_.Runtime.ConnectionState -eq "connected"}|?{!($_.Config.Flags.VirtualExecUsage -eq "hvauto" -and $_.Config.Flags.VirtualMmuUsage -eq "off")}|%{($_.ReconfigVM_Task((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{flags=(New-Object VMware.Vim.VirtualMachineFlagInfo -property @{virtualExecUsage="hvauto";virtualMmuUsage="off"})})))}

C’est beau mais pas vraiment pratique à maintenir à cause des erreurs possibles via la GUI. De plus, nous avons eu l’opportunité précieuse d’échanger avec un Senior Staff Engineer de chez VMware qui nous a laissé entendre que ce n’était pas la meilleure option :

The sw-mmu [...] has slightly higher overheads (for the shadow pagetables and related data structures) and this will reduce the total available memory for backing guest pages.

Dans notre grande quête d’overcommit, notre contact chez VMware nous a parlé d’un paramètre assez génial qui permet de changer la politique d’allocation agressive de large pages de la mmu (en anglais c’est plus facile à comprendre) :

The heuristic, when enabled, basically says that whenever possible when backing any part of a 2MB-region of guest memory, try to do so with a large 2MB page. This may involve remapping existing small 4KB pages into that new 2MB page. But it basically tries to aggressively back everything large

Ce qui explique pourquoi, par défaut, TPS n’a presque pas d’effet (sauf pour les zero) même pour les guest qui ne “demandent” pas de large pages. La raison est bien liée aux performances :

When overcommitment isn’t an issue, large pages really do help TLB-performance with hw-mmu on most workloads.

A l’inverse, si on passe le paramètre à 0 (sched.mem.alwaysTryLPageAlloc pour une vm ou LPage.LPageAlwaysTryForNPT pour un host) la mmu n’allouera une large page qu’à la demande du guest. L’explication est d’ailleurs disponible au fin fond du documentation center de VMware :

Try to allocate large pages for nested page tables (called ‘RVI’ by AMD or ‘EPT’ by Intel). If you enable this option, all guest memory is backed with large pages in machines that use nested page tables. If NPT is not available, only some portion of guest memory is backed with large pages.

Vous aurez compris où nous voulons en venir : trouver un bon équilibre entre le bénéfice en matière de performance des large pages (presque incontestable lorsque c’est le guest qui en fait la demande) et le bénéfice de TPS en matière de consolidation mémoire. Exemple sur notre fameux cluster :

Si vous êtes attentif vous aurez remarqué qu’il n’y a que très peu de différence de consolidation avec les résultats en mode small pages forcées, c’était une feinte pour ceux du fond qui ne suivent pas… Dans ce cas c’est parfaitement normal car aucun des guestOS présent dans cet exemple n’utilise de large pages (windows 2003 32bit). Si les vm avaient été, par exemple, des windows 2008 R2, le niveau de consommation se serait situé quelque part entre le “full” large pages et le “full” small pages en fonction des applications et du comportement de l’OS. Nous ne manquerons pas de compléter ce post avec un exemple impliquant des guestOS et des applications exploitant les large pages.

Voici la commande powershell qui a permis de désactiver sched.mem.alwaysTryLPageAlloc sur les vm (vm reboot ou “vmotion shake” pour la prise en compte) :

Get-View -ViewType VirtualMachine|?{!$_.Config.Template -and $_.Runtime.ConnectionState -eq "connected"}|?{!($_.Config.ExtraConfig|?{$_.Key -eq "sched.mem.alwaysTryLPageAlloc"}|?{$_.value -match "false|0"})}|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{extraconfig=(New-Object Vmware.Vim.OptionValue -Property @{Key="sched.mem.alwaysTryLPageAlloc";Value="0"})}))}

Pour afficher un tableau récapitulatif des infos qui nous intéressent :

Get-View -ViewType VirtualMachine|?{!$_.Config.Template -and $_.Runtime.ConnectionState -eq "connected"}|select @{n="VM";e={$_.Name}}, @{n="HV";e={$_.Config.Flags.VirtualExecUsage}}, @{n="HVMMU";e={$_.Config.Flags.VirtualMmuUsage}}, @{n="disable_mmu_largepages";e={($_.Config.ExtraConfig|?{$_.Key -eq "monitor_control.disable_mmu_largepages"}).value}}, @{n="alwaysTryLPageAlloc";e={($_.Config.ExtraConfig|?{$_.Key -eq "sched.mem.alwaysTryLPageAlloc"}).value}}, @{n="ESX";e={(Get-View -property Name $_.Runtime.Host).Name}}|sort hv,hvmmu,disable_mmu_largepages,alwaysTryLPageAlloc,ESX|ft -AutoSize

Pour information, depuis ESXi 5.0, il existe une commande très utile pour monitorer l’utilisation des large pages (memstats -r lpage-stats -v) :

En cas de vmotion, les pages de la “future” vm sont allouées au format 4k et reconverties par la suite :

The vmkernel allocates the memory for a VM during precopy using small pages. These are then converted to large as the VM begins to run but it is based on guest accesses. esx5.0 and esx5.1 each improved on the ability to recover the large mappings.

Et parce que nous sommes de grands fan de l’overcommit mémoire, voici notre poudre de perlimpinpin à ajouter dans vos recettes de scripts de déploiements si vous voulez overcommiter bien comme il faut (nous déclinons toute implosion de votre infra…) :

vim-cmd hostsvc/advopt/update VMkernel.Boot.sharePerNode bool false
vim-cmd hostsvc/advopt/update Mem.ShareRateMax long 32768
vim-cmd hostsvc/advopt/update Mem.ShareScanTime long 10
vim-cmd hostsvc/advopt/update Mem.ShareScanGHz long 32
vim-cmd hostsvc/advopt/update Mem.IdleTax long 95
#vim-cmd hostsvc/advopt/update Mem.AllocGuestLargePage long 0
#vim-cmd hostsvc/advopt/update Mem.AllocGuestRemoteLargePage long 0
#vim-cmd hostsvc/advopt/update LPage.LPageAlwaysTryForNPT long 0
vim-cmd hostsvc/advopt/update Mem.MemZipMaxPct long 25
#vsish -e set /sched/freeMemoryState/minFreePct 3

Nous finirons par une petite citation pour ceux qui ne jurent que par les large pages (qui a dit Hyper-V ?!) :

The performance increase is somewhat dependant upon the type of workload the virtual machine is executing; memory-intensive applications see more performance improvement than applications that are not heavily dependent on memory access.

Un grand merci à Alex Garthwaite pour son aide à la rédaction de ce post et à la compréhension des mécanismes de gestion de la mémoire d’ESX.

L’initiative pourrait rester valable si elle n’était pas gavée de gros morceaux de bullshit comme ce magnifique tableau comparatif :

Notre bullshit-o-meter, déjà dans le rouge, a totalement grillé sur la séquence comparative Core Parking vs DPM (extrait ci-dessus). Notre brave Symon (“Microsoft Technical Evangelist” en chemise bleu) semble persuadé qu’un serveur allumé consomme autant qu’un serveur éteint (où l’inverse). Et pourtant :

The Core Parking feature allows Windows Server 2008 R2 to consolidate processing onto the fewest number of possible processor cores, and suspends inactive processor cores

Même si le CPU représente une part non négligeable de la consommation d’un serveur, il n’est question en moyenne que d’1/4 à 1/3 de la consommation totale. Mais quelque chose nous dit que M$ a fini par s’en apercevoir, ils n’ont juste pas encore prévenu Symon. Néanmoins, pour pouvoir consolider au maximum il faut un peu mieux que Dynamic Memory…

Démonstration avec un cluster, hébergeant 66 VM (W2K3 – 2Go), composé de 12 serveurs bi Xeon 5345 + 8Go de RAM sous ESXi 4.1 build 348481. Les VM de ce cluster devant etre dispo à 100% entre 8h et 19h, Distributed Power Management est programmé dans vCenter pour s’activer à 20h et se désactiver à 7h (hors WE). Résultat, 9 serveurs sur 12 OFF (pour Symon, ça veut plus d’électricité du tout) en heures creuses, c’est à dire 60% du temps dans notre cas :

Evidemment, impossible d’atteindre ce taux de consolidation hallucinant de 600% sans l’aide de TPS, Ballooning, Memory compression et Hypervisor swapping :

Ça, c’est du GreenIT et c’est dispo depuis 2008 !

Les tests ont été fait sur un serveur lame IBM LS42 (Opteron 8376 HE / 32Go), nous y avons démarré 30 VM identiques (W2K3EE) à 10sec d’intervalle, avec le paramètre de vMMU forcé. On voit clairement sur le graphique que le TPS “récupère” beaucoup plus de mémoire en swMMU qu’en hwMMU.

Halesh (VMware R&D) nous a confirmé que dans cette situation, le TPS n’agissait que sur les pages “zeroed” au boot de la VM. Seongbeom Kim (VMware) nous en dis plus par mail :

On EPT/RVI platform, large pages are used to back guest memory request for better performance. This delays page sharing until the host goes into memory overcommitted situation.
In more recent updates to ESX4.0 (including build 219382), zero pages are shared in 4K granularity while guestOS boot-process zeros all guest memory.
This approach provides early sharing and can be beneficial for guests that do not access all the configured memory.
Whenever the shared page is broken, we try to back it with large page to achieve better performance.

Mais le plus fort c’est que le vMMU peut être changé à chaud grâce à VMotion (en changeant le paramètre avant le VMotion bien-sur) ! Pour illustrer cette prouesse purement futile, nous avons superposé les 2 graphiques mémoire des 2 hosts :

Nous attendons d’en savoir plus sur la “légitimité” de cette “feature”…

Selon Halesh, le fonctionnement de VMotion explique cet effet :

For VMotion we need common CPUs across source & destination. But as you said during vmotion, vMMU worlds are restarted/newly created on destination this might be supporting.

Tout d’abord, nous vous conseillons vivement de consulter (si ce n’est pas déjà fait) le pdf de Carl A. Waldspurger sur les différentes techniques de “conservation” de la mémoire utilisé par VMware ESX.

Ce document traite notamment de l’un des points fort d’ESX, le Transparent Page Sharing. Pour faire simple, cette fonction fait pointer des pages mémoires identiques (aux seins de différentes VM) vers une page physique.

Voici l’exemple d’un host ESX 3.5 hébergeant 70 VM (presque toutes sous Windows 2003) qui ont 25Go de pages mémoire en commun. Ces 25Go n’occupent que 4Go de RAM physiquement :

D’après VMware, l’overhead de cette fonction n’excéderait pas 1%.

Malheureusement, d’après la récente expérience de Duncan le TPS ne ferait pas bon ménage avec le RVI.

Le RVI (fonctionnalité des CPU AMD) est considéré comme le second niveau de virtualisation matériel. Il permet une accélération matériel de la gestion des transactions vRAM <> pRAM (MMU). En effet, la gestion RAM physique/RAM virtuelle (dans les VM) est traditionnellement gérée de façon logiciel par l’hyperviseur. le RVI permet donc de s’affranchir du coût CPU qu’engendre cette gestion (virtualized MMU).

Jason nous en explique un peu plus sur le fonctionnement du RVI sur son blog et nous informe que la version d’Intel (l’EPT) de cette technologie devrait être disponible dans le courant de l’année.

A la demande de Duncan, Carl nous explique que le RVI fonctionne majoritairement en mode “large pages” (2Mo) ce qui n’est pas compatible avec le TPS (qui ne fonctionne que sur des pages de 4ko).

Cette explication est d’ailleurs confirmée par un white paper VMware sur l’utilisation des “larges pages” :

In ESX Server 3.5 and ESX Server 3i v3.5, large pages cannot be shared as copy‐on‐write pages. This means, the ESX Server page sharing technique might share less memory when large pages are used instead of small pages.

Nous ignorons encore de quelle différence il est question mais le véritable problème est une possible dégradation de performance en cas de memory overcommit trop important:

When free machine memory is low and before swapping happens, the ESX Server kernel attempts to share identical small pages even if they are parts of large pages. As a result, the candidate large pages on the host machine are broken into small pages.