[ARTICLE] [ESXI] Etude sur le comportement d’une VM et du mode Turbo Boost

J’ai récemment été confronté à un use case assez particulier avec une VM qui pouvait consommer plus de fréquence par cœur qu’il n’était possible, et ce sans qu’aucun autre workload ne tournait sur l’ESXi. Et bien évidemment aucun graphs ne montrait la réponse.

Avant de commencer, le cluster était constitué de 3 VxRail V670F Intel Xeon Gold 6354 cadencé à 3 Ghz (ESXi bi-socket), et tous les ESXi étaient configurés en mode « High Performance » sur le vCenter.

Pour information même si elles n’ont pas d’importances sur cet article voici les versions:

• ESXi 7.0.3, 19482537
• vCenter 7.0.3 20051473

Avant toute chose, et pour rappel une VM ne pourra jamais consommer plus de ressources que ce que possèdent le(s) serveur(s) physique(s), mais ce qui en soit est normal. Donc si on suit la logique en prenant notre infrastructure ci-dessus, une VM de 16 vCPU ne pourra pas consommer au-delà de 48 Ghz à pleine charge.
Pour trouver ces 48 Ghz il faut se baser sur la formule suivante :

16 vCPU (configuration vCPU de la VM) * 3 Ghz (fréquence de chaque cœur du serveur physique) = 48 Ghz.

Et etrangement cette VM pouvait consommer jusqu’à ~52,4 Ghz à pleine charge sous OCCT.

Alors oui, on peut se dire que la différence entre 48 Ghz et 52,4 Ghz est anodine et est-ce que ça vaut le coup de « perdre du temps » à chercher le pourquoi du comment, mais sur une infrastructure mutualisée cela peut représenter jusqu’à 9% de consommation en moins, et donc si l’on prend en exemple un ESXi où l’on peut mettre un maximum de 100 VMs, avec cette différence de 9% nous pourrions en mettre environ 9 VMs de moins. (je vous l’accorde le calcul n’est pas aussi simple que ça, et surtout on ne le calcule pas de cette manière mais c’est pour l’exemple).

Donc pour reprendre cette histoire voyons comment cela est possible, et surtout est-ce qu’il y a un impact sur les performances côté OS.

Toud d’abord sur l’iDRAC nous pouvons voir que la fréquence des 2 processeurs est bien de 3Ghz, mais nous voyons également que le Turbo Boost est activé, logiquement c’est lui qui est à l’origine du problème.
Spoiler: Oui, mais il ne fait pas tout.

Charge d’une VM sous OCCT avec 16 vCPU / 128 Go RAM

Sur ce premier test de charge nous pouvons voir que la VM consomme bien un maximum de ~52,4Ghz, et qu’elle n’a aucun signe de problème de performance (pas de %RDY, pas de %CSTP,..) ce qui est logique parce qu’elle ne sature pas l’ESXi qui lui a 18 cœurs physiques, et qui a une fréquence maximale de ~108 Ghz (18 cœurs physiques * 3 Ghz de fréquence * 2 sockets)

Charge de 3 VMs 16 vCPU / 128 Go RAM sous OCCT

Cette fois-ci les graphs, ESXTOP, et le performance charts sur vCenter nous donnent un peu plus d’informations précises.

Donc si nous prenons les « VMs lists » sur l’ESXi nous pouvons voir les 3 VMs avec une charge de 100% avec une consommation totale additionnée de 121.17 Ghz, ce qui correspond bien au mode Turbo Boost du processeur si l’on suit la documentation officielle Intel qui indique que ce processeur est capable de monter à 3.60 Ghz par cœur.

Cependant nous pouvons aussi voir que le vCenter n’a pas connaissance de ce mode Turbo Boost.
En fait sur son performance chart il affiche un max de 107.71 Ghz ce qui correspond à 18 cœurs physiques * 3 Ghz de fréquence * 2 sockets = ~108Ghz.

Aussi, les VMs ont des valeurs très correctes sur ESXTOP :

• CPU Ready
• %VMWAIT (source VMware: « VMWAIT is only applicable to the vCPU Worlds of a virtual machine. VMWAIT doesn’t sum up the idle time. »).
• %OVRLP

Globalement on peut observer que les VMs sont saines même si elles sont très peu « scheduler », et on peut également observer que les 120 Ghz sont biens réparties entre les 3 VMs.

Saturation de l’ESXi avec 4 VMs :

Sur les graphs ci-dessous on peut toujours voir que la répartition est équivalente entre chaque VM. Cependant, un autre paramètre rentre en compte parce que si l’on additionne les ressources des 4 VMs elles consomment maintenant ~135.57 Ghz.

Si le Turbo Boost peut « overclocker » la fréquence de 3Ghz à 3,60 Ghz comment les VMs peuvent-elles consommer plus ? Sachant qu’il reste impossible qu’une (ou des VMs) puisse consommer plus que les ressources physiques, donc il y a forcément une feature qui entre en compte dans cet extend de 15 Ghz.

Après quelques recherches, et d’après une KB VMware le vCenter peut « overclocker » la fréquence jusqu’à 125%, donc si l’on prend un VxRail V670F Intel Xeon Gold 6354 cadencé à 3 Ghz et que l’on applique +125% à 3 Ghz nous obtenons 3.75 Ghz. Et ces 3.75 Ghz * 18 cœurs physiques * 2 sockets nous avons nos fameux 135 Ghz.

Saturation d’un ESXi avec 5 VMs.

Le dernier test de cet article concerne 5 VMs au lieu des 4 qui nous ont permis de vérifier d’où provenait cette consommation de fréquence. Donc nous pouvons voir qu’elles ont toutes plus ou moins la même consommation mais par contre nous voyons des choses plus intéressantes sur la partie ESXTOP

A partir de 5 VMs l’ESXi schedule et bride les consommations de VMs par du %READY et du %CSTP.

Conclusion :

Les VMs peuvent consommer l’entièreté de la fréquence maximale (120 Ghz) que peut proposer le processeur physique via le mode Turbo Boost. Cependant, le vCenter n’a pas connaissance de ce delta de fréquence qui fait que l’ESXi peut passer 108 Ghz à 120 Ghz (ou plus exactement de 3 Ghz à 3,60 Ghz).

Aussi, les VMs ne sont pas « schedulées » tant qu’elles ne dépassent pas le nombre de 4 VMs (pour ce use case), et au-delà toutes les VMs sont « schedulées », c’est d’ailleurs ce que nous avons pu voir très clairement avec un ESXTOP (via %RDY et %CSTP entres autres).

Par contre, un point important que je n’ai pas vraiment réussi à démontrer est que le vCenter est capable de gérer le mode Turbo Boost au travers du « Performance Mode » en faisant un « overclocking » de 125%. Comme nous l’avons vu, cela nous donne bien les 15 Ghz d’extend lorsque nous faisons tourner plus de VMs que l’ESXi peut supporter. Cependant, il semblerait que le vCenter soit aussi capable de gérer le mode Turbo Boost en lui appliquant une configuration spécifique en passant la fréquence de 3.60 Ghz à 3.75 Ghz.

Mais ce qui m’amène à me poser plusieurs questions telle que « est-ce que la version du vCenter est liée, et comment le vCenter arrivent-il à jouer sur les tensions du processeur physique ? Si c’est bien de cette manière qu’il agit ».

Sources :
Processeur Intel® Xeon® Gold 6354
https://ark.intel.com/content/www/fr/fr/ark/products/212460/intel-xeon-gold-6354-processor-39m-cache-3-00-ghz.html
Testing CPU Max Turbo Boost Frequency in ESXi (80610)
https://kb.vmware.com/s/article/80610
Troubleshooting a virtual machine that has stopped responding: VMM and Guest CPU usage comparison (1017926)
https://kb.vmware.com/s/article/1017926
Why is %WAIT so high in esxtop?
https://www.yellow-bricks.com/2012/07/17/why-is-wait-so-high/