Le 02 octobre 2013 un article a été publié sur le blog de VMware ayant pour sujet l’impact de l’élément de configuration « corespersockets » sur les performances processeur avec VMware vSphere : « Does corespersockets Affect Performances ? »
L’article expose au moyens de différents tests les effets néfastes ou non de différentes configurations CPU pour un même traitement.
Pourquoi parler de cet article ? Tout simplement parce que c’est le plus populaire et le seul qui traite ouvertement du sujet sur internet. On trouve certes des explications sous formes d’articles techniques sur les impacts potentiels d’une mauvaise configuration processeur, mais rarement sous la forme de benchmark comme c’est le cas ici.
Cependant, les résultats sont lancés par VMware « brute de fonderie » sans fournir de réelles explications. Essayons d’apporter un éclairage sur cette problématique.
Pour comprendre la suite, je vous recommande notre dernier article sur le sujet et bien évidemment d’avoir lu le billet de blog VMware : « Does corespersockets Affect Performances ? »
Les caractéristiques de la machine de l’équipe de test
Dans l’article de blog de VMware, c’est une machine Dell R815 qui est utilisée. Elle à la particularité d’utiliser un processeur AMD Opteron 6174 qui est composé de :
- 4 sockets
- chacune de ces sockets contient 12 processeurs répartis en 2 CPU packages
- pour un total de 48 processeurs
On a donc 8 noeuds NUMA de :
- 6 processeurs
- 32 Go de RAM
Retour sur les tests effectués
Test 1 – vSocket: 24 ; corespersocket: 1
Ce premier test suis à la lettre les bonnes pratiques de VMware (cf. Performance Best Practices for VMware vSphere® 5.5) :
When creating a virtual machine you have the option to specify the number of virtual sockets and the number of cores per virtual socket. In general, we recommend leaving this at the default value of 1 core per socket (with the number of virtual sockets therefore equal to the number of vCPUs).
If the number of cores per virtual socket on a vNUMA-enabled virtual machine is set to any value other than the default of 1, and that value doesn’t align with the underlying physical host topology, performance might be slightly reduced.
Vous trouverez la topologie processeur suivante :
C’est sans surprise le test qui fournit les meilleurs résultats. Pourquoi ? Parce que laisser l’option « corespersocket » à 1 revient à laisser l’ESXi traiter lui même la question de la topologie processeur. Et très souvent, il le fait beaucoup mieux que nous.
Ici, VMware va donc :
- Aligner chaque VPD sur les PPD
- Aligner chaque vNUMA sur les VPD
- Aligner chacune des vSockets en fonction du vNUMA
Au niveau de la machine invitée (machine virtuelle), l’OS voit 4 noeuds NUMA, ce qui correspond exactement à la réalité hardware. Il sera ainsi à même d’optimiser ses processeurs et sa mémoire vive.
Test 2 – vSocket: 2 ; corespersocket: 12
Ici on modifie le nombre de cores par socket avec la valeur 12. On contraint donc VMware à utiliser 2 vSockets (2 x 12 vCPU = 24 vCPU) et ainsi 2 vNUMA. L’OS sur la machine invitée voit 2 noeud NUMA au lieu des 4 véritables.
Le schéma suivant résume la topologie :
On peut s’attendre à deux grands types de problèmes :
- des problèmes d’optimisations sur la machine invitée
- L’OS de la VM va chercher à optimiser les travaux processeurs et les accès à la mémoire par rapport aux informations dont il dispose, c’est à dire 2 noeuds NUMA au lieu de 4. Les optimisations vont donc s’avérer contre-productives
- des problèmes d’optimisation au niveau de l’ESXi
- La mémoire va vite se retrouver répartie entre les deux NHN (NUMA Home Node) et des accès en remote vont apparaitre
- Le travaille du CPU scheduler au sein de l’ESXi va s’en trouver affecté et on peut s’attendre à beaucoup de context switch
Les traitements s’en trouvent impactés ce qui explique un temps d’exécution de 17% plus long par rapport au test précédent.
Difficile ici de donner plus de détails n’ayant pas accès aux tests effectués sur les machines virtuelles dans l’article :
- Y a t’il une utilisation massive de RAM ?
- Les cycles CPU demandés étaient-ils court ou long ?
- etc.
Test 3 –vSocket: 1 ; corespersocket: 24
C’est le même principe ici que dans le test précédent mais en pire. Le système d’exploitation de la machine invitée ne voit plus qu’un seul noeud NUMA. Il n’y aura donc pas d’optimisations possibles de la part de l’OS. L’impact sur les traitements est de 31% par rapport au premier test.
Essayons d’aller un peu plus loin
Dans cet article, les auteurs se sont principalement concentrés sur l’impact de mauvaises configurations sur la performance processeur. Il est dommage de ne pas avoir poussé l’expérience plus avant en montrant un éventuel impact d’une configuration qui aligne le paramètre « corespersocket » avec la taille des noeuds NUMA.
Les bonnes pratiques de VMware recommandent deux configurations :
- Dans tous les cas, la configuration par défaut (test 1)
- Si vous maîtrisez votre infrastructure de bout en bout (ce qui est le cas dans un lab), VMware recommande d’aligner le nombre de vSockets avec le nombre de CPU par noeud NUMA, ici : vSocket: 4 ; corespersocket: 6
[…] Therefore if a virtual machine is to be configured with a non-default number of cores per virtual socket, for best performance that number should be an integer multiple or integer divisor of the physical NUMA node size.
In some cases, setting the number of cores per virtual socket to the number of cores per physical NUMA node shows a performance improvement.
Cette configuration aurait donnée la modélisation suivante :
Ce qui change avec ce paramétrage c’est que la stack complète, de la vSocket au PPD, est alignée. Est-ce que de cet alignement il en résulte un gain de performance ? Si oui, est-il significatif ?
D’autre part, l’équipe a pris le parti d’utiliser un processeur AMD donc sans hyperthreading. Quelle est l’impact ou le gain de l’hyperthreading sur les performances CPU ? L’impact de mauvaise configurations CPU est-elle encore plus significative avec de l’hyperthreading ? Les tests effectués étaient-ils massivement threadés ou prenait-il en compte cette absence ?
Conclusion
L’article « Does corespersockets Affect Performances ? » met en évidence deux choses :
- Oui, modifier l’option « corespersocket » peut affecter les performances de vos machines virtuelles
- L’impact peut-être très élevé, de l’ordre de 30%
Cependant l’article ne couvre qu’une portion des problématiques autour de la performance processeur dans un milieu virtualisé. Et les tests effectués restent assez loin des problématiques d’environnements de production :
- Aujourd’hui, les OS ne sont pas les seuls à optimiser leurs traitements par rapport aux noeuds NUMA
- Quelle est l’impact d’une mauvaise configuration CPU quand un middleware (serveur d’application, progiciel, base de données) en plus de l’OS optimise ses traitements par rapport à la topologie processeur ?
- Ces middlewares, largements utilisés dans les SI, peuvent avoir des workloads processeur de nature très différentes. Y a t’il des configurations à préférer dans le cadre :
- de workload courts mais intenses (ex : serveurs web)
- de workloads plus longs mais d’intensité plus faible (ex : base de données)
- On retrouve plus souvent des serveurs x86 Intel dans les datacenters
- l’activation de l’hypertheading à des impacts sur la performance des machines (de l’ordre de 10 à 15% par expérience personnelle) dans certains contextes
- Ces 15%, d’apparence insignifiant, ont leur importance en fonction du périmètre fonctionnel auxquels ils sont liés (ex : trading)
- Le terme « impact » n’est pas forcément que négatif, il peut y avoir des impacts positif
- Quels sont les gains de performance lorsque la configuration processeur des machines virtuelles est parfaitement alignée sur topologie CPU ?
- Quels sont les impacts d’une telle configuration à l’échelle d’une production (plusieurs clusters ESXi avec un nombre conséquent de VMs) ?
- …
Et encore beaucoup de questions auxquelles nous essaieront de répondre dans les mois qui viennent.