Vous allez me dire “on s’en fout bien du swMMU, c’est old school et on a plus de VM sous Windows 2000 !” et je suis bien d’accord avec vous mais Duncan a récemment posté un billet très intéressant sur les notions de static et dynamic overhead et en particulier sur la réservation de mémoire lors d’un vmotion.

[...] the vMotion process aims to be conservative and uses static overhead memory instead of dynamic

Vous l’aurez compris, en swMMU c’est du static et en hwMMU c’est du dynamic mais pour certaines actions, les valeurs du static overhead font référence. Dans le cas d’une mise à jour d’un cluster un peu chargé cela peut avoir toute son importance compte tenu de l’écart de réservation être les deux techniques :

Et pour ceux qui aiment se faire du mal, on a essayez avec 1TB de vRAM (merci l’overcommit) :

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.

En toute honnêteté, pendant 2 secondes nous avons pensé à une killer feature qui permettrait de placer automatiquement la swap du GuestOS sur un vdisk à part ou quelque chose d’encore plus ingénieux. On y croyait vraiment à mort tant la feature list d’Hyper-V 3 est impressionnante (pour un produit “gratuit”).

Mais non, c’est juste le fichier de swap de la vm qui va avec une autre nouvelle fonction “minimum memory”. Je vous laisse apprécier le descriptif :

Dynamic Memory improvements include support for configuring minimum memory, and Smart Paging, which is a memory management technique to provide a reliable restart experience for virtual machines configured with less minimum memory than startup memory.
[...]
Smart Paging uses disk resources as additional, temporary memory when more memory is required to restart a virtual machine than the amount of memory currently allocated to a virtual machine.

Ça c’est du dépoussiérage de feature où on s’y connait pas ! Mais c’est pas fini, on vous a gardé le meilleur pour la fin :

To minimize the potential performance impact of Smart Paging, HyperV uses it only when all of the following occurs:

1. The virtual machine is being restarted.
2. There is no available physical memory.
3. No memory can be reclaimed from other virtual machines running on the host.

Et on vous rafraîchi la mémoire sur ce qu’M$ pensait de l’overcommit quand Hyper-V n’en était pas capable :

What this means is while Memory Overcommit has its uses in certain configurations, it’s not a panacea for virtualization administrators. Memory Overcommit should be used judiciously and only when absolutely necessary.

Sachez aussi qu’historiquement statiques, les pourcentages équivalent aux différents states sont “dynamique” depuis ESX 5 et VMware recommande de tuner le paramètre minFreePct sur ESX 4.1 au dessus de 64Go de ram (nous, on vous recommande 3% à partir de 32Go).

Le compteur n’est pas accessible pour faire une alarme dans le vcenter donc nous avons fait chauffer le PowerCLI pour vous en faire une belle qui brille dans la nuit et qui vous alerte dès que le compteur passe à 1 (=1 : warning, >1 : alert) :

(Get-View AlarmManager).CreateAlarm((Get-Folder -NoRecursion |Get-View).MoRef,(New-Object VMware.Vim.AlarmSpec -Property @{Name = "Host memory state";Description = "Custom alarm to monitor Host memory state high-soft-hard-low";Enabled = $true;expression = (New-Object VMware.Vim.OrAlarmExpression -Property @{expression = @((New-Object VMware.Vim.MetricAlarmExpression -Property @{Metric = (New-Object VMware.Vim.PerfMetricId -Property @{CounterId = ((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "mem"}|?{$_.nameinfo.key -match "state"}|?{$_.RollupType -match "latest"}).key;Instance = ""});Operator = "isAbove";Yellow = "1";YellowInterval = "20";Red = "2";RedInterval = "20";Type = "HostSystem"}))});Action=(New-Object VMware.Vim.GroupAlarmAction -Property @{Action= (New-Object VMware.Vim.AlarmTriggeringAction -Property @{Action = (New-Object VMware.Vim.SendEmailAction -Property @{ToList = "admin@vmware.local";Subject = "[vAlarm] {targetName} memory state is {newStatus}";CcList = "";Body = ""});TransitionSpecs = @((New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "green";FinalState = "yellow";Repeats = $false});(New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "yellow";FinalState = "red";Repeats = $true}))})});ActionFrequency = "1800"}))

Get-View -ViewType VirtualMachine -Property Config,Summary,Runtime|?{$_.Runtime.PowerState -eq "PoweredOn" -and $_.Runtime.ConnectionState -eq "connected"}|%{$_.Config.Hardware.MemoryMB - $_.Summary.QuickStats.HostMemoryUsage}|Measure-Object -Sum -Minimum -Maximum -Average

Sur une infra d’environ 1500 VM, ça donne environ 2,4To de RAM récupérée sur 4,5To. C’est assez énorme :

Et chez vous ça fait combien ?

(1-contention rapide / 2-contention lente)

De plus, comme indiqué dans le Resource Management Guide, plus la VM est riche en vCPU et en vRAM, plus elle imposera un overhead important au VMkernel. Cet overhead est réservé et donc totalement “perdu”. Il ne sera pas non plus soumis aux differents mécanismes de récupération d’ESX (Transparent Page Sharing > Memory Idle Tax/Ballooning > Memory Compression > Hypervisor Swapping).

On ne parle que d’une centaine de Mo pour une VM avec 1 vCPU et 1Go de vRAM, mais un petit one-liner de PowerCLI nous permet de savoir de combien on parle pour une infra de plus de 1200 VM :

Write-Host -ForegroundColor Red -BackgroundColor Yellow $([math]::round((Get-View -ViewType virtualmachine -Property Summary,Runtime|?{$_.runtime.PowerState -eq "poweredOn"}|select -ExpandProperty Summary|select -ExpandProperty Runtime|Measure-Object -Sum -Property MemoryOverhead).sum/1GB,1)) / $([math]::round((Get-View -ViewType virtualmachine -Property Summary,Runtime|?{$_.runtime.PowerState -eq "poweredOn"}|select -ExpandProperty Summary|select -ExpandProperty Config|Measure-Object -Sum -Property MemorySizeMB).sum/1KB,1))

Presque 220Go d’overhead sur environ 3,8To de vRAM attribué, soit près de 6% !

Il est donc nettement plus judicieux de bien determiner la taille de vRAM nécéssaire au “Guest OS“ et de tailler au plus juste plutot que mettre une valeur trop large au risque de voir la VM en souffrir plutot que d’en bénéficier (idem pour les vCPU d’ailleurs).

A lire tous les soirs après s’etre brossé les dents : Understanding Memory Resource Management in VMware ESX 4.1

VMware, soucieux de conserver son avance en la matière, ajoutera un nouveau mécanisme de memory overcommit dans sa future version : la “memory compression”. Il s’agirait d’une compression dynamique de pages, ultime étape avant le swapping.

HyperviZor.com a d’ailleurs dédié un superbe diagrame à ce sujet :