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 !

Rappelons que (dans ce contexte) le vNUMA est la capacité de présenter à la VM une topologie NUMA identique à celle de sa VMM. Cette technique permet au guestOS d’optimiser lui même la répartition process/node pour éviter au maximum les accès à des pages qui ne seraient pas dans le noeud où se trouve le vCPU qui y accède (aka remote access).

L’idéal serait un des schémas percutant dont Frank Denneman à le secret mais il va falloir vous contenter de cela : le vNUMA est le WYSIWYG transposé au NUMA donc la topologie NUMA que la VM “voit” est véritablement celle de sa VMM.

Présente depuis ESX 5.0, cette fonctionnalité n’est active par défaut que pour les VM avec *strictement* plus de 8 vCPU (=>9 et non 8+) mais VMware indique comment l’activer pour les VM plus petites :

By default, vNUMA is enabled only for virtual machines with more than eight vCPUs. This feature can be enabled for smaller virtual machines, however, by adding to the .vmx file the line: numa.vcpu.maxPerVirtualNode = X (where X is the number of vCPUs per vNUMA node).

Ce qui est à moitié vrai car avec ce paramètre vous ne forcez que la répartition des vCPU par vNode (topologie présentée à la VM) et non celle des vCPU par pNode (topologie réelle). Heureusement VMware documente plutôt généreusement (en général) et nous avons trouvé l’autre moitié de la réponse dans le Documentation Center :

numa.vcpu.maxPerMachineNode Maximum number of virtual CPUs that belong to the same virtual machine that can be scheduled on a NUMA node at the same time. Use this attribute to ensure maximum bandwidth, by forcing different NUMA clients on different NUMA nodes.

Résultat, même avec 2 vCPU on peut faire du beau vNUMA (avec un beau oneliner) :

Get-VM|?{$_.NumCpu -eq 2}|Get-View|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{extraconfig=@((New-Object VMware.Vim.optionvalue -Property @{Key="numa.vcpu.maxPerVirtualNode";Value="1"});(New-Object VMware.Vim.optionvalue -Property @{Key="numa.vcpu.maxPerMachineNode";Value="1"});(New-Object VMware.Vim.optionvalue -Property @{Key="cpuid.coresPerSocket";Value="1"}))}))}

Et on a même fait des bench (sur un Intel E7520) avec Sandra 2013 pour voir s’il pouvait y avoir un gain (vNUMA en bleu, vUMA en rouge) !

Le gain est mince (contrairement aux grosses VM pour faire du HPC) mais sur un host bien overcommité cela peut avoir un véritable intérêt (avant/après) :

Nous avons eu la chance d’avoir l’avis de Seongbeom Kim (Senior Member of Technical Staff chez VMware) sur l’intérêt d’une telle manipulation et sur la raison pour laquelle, contrairement à Hyper-V, vNUMA n’est pas actif par défaut sur les petites VM :

Based on your two charts, enabling vNUMA looks good by not migrating memory across NUMA nodes, resulting in 100% local memory.

One consideration should be whether your workload benefits from cache sharing or not. By forcing vcpus scheduled on two or more NUMA nodes, workload with heavy cache sharing may suffer performance loss even with better memory latency.

For a new VM*, it may pay off to try vNUMA for your VM if #vcpus is greater than the number of cores per NUMA node. The benefit heavily depends on the workload behavior.

[...] modern processors have enough number of cores to place 2 – 4 vcpu VM on a NUMA node where vNUMA has no benefit. Even 8 cores per NUMA node is not rare.

Par “nouvelle VM”, Seongbeom sous entend qu’il y a un risque que le changement de topologie NUMA ait un impact sur le GuestOS et/ou l’application hébergée dans la VM.

esxtop command showing high %RDY values for virtual machines running on NUMA enabled ESX/ESXi 4.0 hosts :

If the virtual machine has a higher number of vCPUs than the number of cores in the NUMA node, then the virtual machine is not managed by the NUMA Scheduler and there are no benefits from NUMA locality.

esxtop command showing high %RDY values for virtual machines running on NUMA enabled ESX/ESXi 4.1 hosts :

If the virtual machine has a higher number of vCPUs than the number of cores in the NUMA node, then the vCPUs are broken down into clients that are scheduled on multiple nodes.

Lorsque vous constatez des valeurs élevées sur le compteur Ready Time, il est donc important de s’assurer de la version d’ESX car les causes et conséquences selon les versions ne sont pas du tout les mêmes.

Nous vous recommandons la lecture de l’excellent article ESX 4.1 NUMA SCHEDULING de Frank Denneman décrivant les conséquences du split de client NUMA sur les performances de la VM.

Pour la petite histoire, le NUMA est supporté par ESX depuis la version 2.0 sortie Q3 2003…