vNUMA : WYSIWYG
Posted by NiTRo | Filed under Performance, Tips & Tricks, VMware
Dans l’optique de rattraper un peu le coût CPU de nos petits excès d’overcommit, nous nous sommes penché sur les gains potentiel du vNUMA “forcé” sur des petites VM (2 ou 4 vCPU).
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.
Loading ...
January 10th, 2013 at 20:39
Justement j’ai un peu planché sur le NUMA et l’utilité du vNUMA pour du HPC sous VMware.
Voici un article qui pourrait t’intéresser -> http://blogs.vmware.com/performance/2010/09/hpc-application-performance-on-esx-41-stream.html
January 10th, 2013 at 20:48
Tu vas nous faire un petit feedback ?
January 11th, 2013 at 9:20
Même un post
http://deinoscloud.wordpress.com/2012/12/24/could-dino-be-the-future-of-vsphere-numa-scheduler/
January 12th, 2013 at 12:34
Oui je l’avais vu celui la et le pdf aussi d’ailleurs, très bon tout ça
January 16th, 2013 at 12:22
Une ptite question pour les test de perf. Est ce la version gratuite de sisoft sandra qui est utilisée ?
Merci.
January 16th, 2013 at 12:37
bonjour, non c’est une version pro et nous avons désactivé la limitation de ram/2 et nous avons monitoré le remplissage des nodes. C’était votre inquiétude ?
January 16th, 2013 at 14:24
Non. Je cherche à faire ce type de graphe de perf alors je me demandais quelle version était utilisé dans votre post.
Merci pour l’info dans tout les cas.
January 28th, 2014 at 12:02
Bonjour,
Super boulot ! Vous avez pas mal éclairci mes idées avec vos essais
Par contre je me demandais: Y’a t’il une raison particulière pour laquelle vous avez choisi de modifier simultanément les 2 paramètres “numa.vcpu.maxPerVirtualNode” et “numa.vcpu.maxPerMachineNode” plutôt que de simplement passer par le paramètre “numa.vcpu.min” ?
January 28th, 2014 at 12:13
Au temps pour moi !
Je viens de comprendre que la seule activation de vNUMA sur vos gros processeurs n’aurait pas suffi à forcer le split sur 2 Nodes distincts de vos 2 vCPUs.
January 28th, 2014 at 15:29
Merci pour votre commentaire
En effet, cela permet de “locker” la config dans tous les cas.
January 30th, 2014 at 17:21
Re !
Je me permet de vous embêter à nouveau car vous avez l’air d’avoir bien planché le sujet et qu’en plus vous êtes réactifs
A vrai dire j’ai beaucoup lu sur NUMA et vNUMA ces derniers jours et je suis désormais confronté à un problème où la pratique ne confirme pas ce que je pensais avoir compris de la théorie. En gros, j’ai plusieurs VMs à 8 vCPUs sur des ESXi équipés de procos 6 coeurs et pas de vNUMA activé. Je m’attendais à un fort taux de remote memory que j’aurais pu pointer du doigt mais “malheureusement” l’ESXi m’a roulé dans la farine en présentant sur chacune de ces VMs un taux N%L de 100% !!
Si vous avez une idée de la raison derrière tout ça, n’hésitez pas à venir participer sur ce thread que j’ai posté sur vmug:
http://www.vmug.fr/topic/24503-besoin-dexplications-sur-le-fonctionnement-du-scheduler-numa/
Je ne vous cache pas que je commence à m’arracher les cheveux sur ce problème et qu’aucune lecture ne m’a pour l’instant apporté de réponse…