Avant toute chose, et pour rappel une VM ne pourra jamais consommer plus de ressources que ce que poss\u00e8dent le(s) serveur(s) physique(s)<\/strong>, 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\u00e0 de 48 Ghz \u00e0 pleine charge. 16 vCPU (configuration vCPU de la VM) * 3 Ghz (fr\u00e9quence de chaque c\u0153ur du serveur physique) = 48 Ghz.<\/p>\n\n\n\n Et etrangement cette VM pouvait consommer jusqu\u2019\u00e0 ~52,4 Ghz \u00e0 pleine charge sous OCCT.<\/p>\n\n\n\n Alors oui, on peut se dire que la diff\u00e9rence entre 48 Ghz et 52,4 Ghz est anodine et est-ce que \u00e7a vaut le coup de \u00ab perdre du temps \u00bb \u00e0 chercher le pourquoi du comment, mais sur une infrastructure mutualis\u00e9e cela peut repr\u00e9senter jusqu\u2019\u00e0 9% de consommation en moins, et donc si l\u2019on prend en exemple un ESXi o\u00f9 l\u2019on peut mettre un maximum de 100 VMs, avec cette diff\u00e9rence de 9% nous pourrions en mettre environ 9 VMs de moins. (je vous l\u2019accorde le calcul n\u2019est pas aussi simple que \u00e7a, et surtout on ne le calcule pas de cette mani\u00e8re mais c\u2019est pour l\u2019exemple).<\/p>\n\n\n\n Donc pour reprendre cette histoire voyons comment cela est possible, et surtout est-ce qu\u2019il y a un impact sur les performances c\u00f4t\u00e9 OS.<\/p>\n\n\n\n Toud d’abord sur l\u2019iDRAC nous pouvons voir que la fr\u00e9quence des 2 processeurs est bien de 3Ghz, mais nous voyons \u00e9galement que le Turbo Boost est activ\u00e9, logiquement c\u2019est lui qui est \u00e0 l\u2019origine du probl\u00e8me. Sur ce premier test de charge nous pouvons voir que la VM consomme bien un maximum de ~52,4Ghz, et qu\u2019elle n\u2019a aucun signe de probl\u00e8me de performance (pas de %RDY, pas de %CSTP,..) ce qui est logique parce qu\u2019elle ne sature pas l\u2019ESXi qui lui a 18 c\u0153urs physiques, et qui a une fr\u00e9quence maximale de ~108 Ghz (18 c\u0153urs physiques * 3 Ghz de fr\u00e9quence * 2 sockets)<\/p>\n\n\n\n Cette fois-ci les graphs, ESXTOP, et le performance charts sur vCenter nous donnent un peu plus d\u2019informations pr\u00e9cises.<\/p>\n\n\n\n Donc si nous prenons les \u00ab VMs lists \u00bb sur l\u2019ESXi nous pouvons voir les 3 VMs avec une charge de 100% avec une consommation totale additionn\u00e9e de 121.17 Ghz, ce qui correspond bien au mode Turbo Boost du processeur si l\u2019on suit la documentation officielle Intel<\/a> qui indique que ce processeur est capable de monter \u00e0 3.60 Ghz par c\u0153ur.<\/p>\n\n\n\n Cependant nous pouvons aussi voir que le vCenter n\u2019a pas connaissance de ce mode Turbo Boost. Aussi, les VMs ont des valeurs tr\u00e8s correctes sur ESXTOP :<\/p>\n\n\n\n Globalement on peut observer que les VMs sont saines m\u00eame si elles sont tr\u00e8s peu \u00ab\u00a0scheduler\u00a0\u00bb, et on peut \u00e9galement observer que les 120 Ghz sont biens r\u00e9parties entre les 3 VMs.<\/p>\n\n\n\n Sur les graphs ci-dessous on peut toujours voir que la r\u00e9partition est \u00e9quivalente entre chaque VM. Cependant, un autre param\u00e8tre rentre en compte parce que si l\u2019on additionne les ressources des 4 VMs elles consomment maintenant ~135.57 Ghz.<\/p>\n\n\n\n Si le Turbo Boost peut \u00ab\u00a0overclocker\u00a0\u00bb la fr\u00e9quence de 3Ghz \u00e0 3,60 Ghz comment les VMs peuvent-elles consommer plus\u00a0? Sachant qu\u2019il reste impossible qu\u2019une (ou des VMs) puisse consommer plus que les ressources physiques, donc il y a forc\u00e9ment une feature qui entre en compte dans cet extend de 15 Ghz.<\/p>\n\n\n\n Apr\u00e8s quelques recherches, et d\u2019apr\u00e8s une KB VMware<\/a> le vCenter peut \u00ab overclocker \u00bb la fr\u00e9quence jusqu\u2019\u00e0 125%, donc si l\u2019on prend un VxRail V670F Intel Xeon Gold 6354 cadenc\u00e9 \u00e0 3 Ghz et que l\u2019on applique +125% \u00e0 3 Ghz nous obtenons 3.75 Ghz. Et ces 3.75 Ghz * 18 c\u0153urs physiques * 2 sockets nous avons nos fameux 135 Ghz. Le dernier test de cet article concerne 5 VMs au lieu des 4 qui nous ont permis de v\u00e9rifier d\u2019o\u00f9 provenait cette consommation de fr\u00e9quence. Donc nous pouvons voir qu\u2019elles ont toutes plus ou moins la m\u00eame consommation mais par contre nous voyons des choses plus int\u00e9ressantes sur la partie ESXTOP<\/p>\n\n\n\n A partir de 5 VMs l\u2019ESXi schedule et bride les consommations de VMs par du %READY et du %CSTP.<\/p>\n\n\n\n Les VMs peuvent consommer l\u2019enti\u00e8ret\u00e9 de la fr\u00e9quence maximale (120 Ghz) que peut proposer le processeur physique via le mode Turbo Boost. Cependant, le vCenter n\u2019a pas connaissance de ce delta de fr\u00e9quence qui fait que l\u2019ESXi peut passer 108 Ghz \u00e0 120 Ghz (ou plus exactement de 3 Ghz \u00e0 3,60 Ghz).<\/p>\n\n\n\n Aussi, les VMs ne sont pas \u00ab\u00a0schedul\u00e9es\u00a0\u00bb tant qu\u2019elles ne d\u00e9passent pas le nombre de 4 VMs (pour ce use case), et au-del\u00e0 toutes les VMs sont \u00ab\u00a0schedul\u00e9es\u00a0\u00bb, c\u2019est d\u2019ailleurs ce que nous avons pu voir tr\u00e8s clairement avec un ESXTOP (via %RDY et %CSTP entres autres).<\/p>\n\n\n\n Par contre, un point important que je n\u2019ai pas vraiment r\u00e9ussi \u00e0 d\u00e9montrer est que le vCenter est capable de g\u00e9rer le mode Turbo Boost au travers du \u00ab Performance Mode \u00bb en faisant un \u00ab overclocking \u00bb de 125%. Comme nous l\u2019avons vu, cela nous donne bien les 15 Ghz d\u2019extend lorsque nous faisons tourner plus de VMs que l\u2019ESXi peut supporter. Cependant, il semblerait que le vCenter soit aussi capable de g\u00e9rer le mode Turbo Boost en lui appliquant une configuration sp\u00e9cifique en passant la fr\u00e9quence de 3.60 Ghz \u00e0 3.75 Ghz.<\/p>\n\n\n\n Mais ce qui m\u2019am\u00e8ne \u00e0 me poser plusieurs questions telle que \u00ab est-ce que la version du vCenter est li\u00e9e, et comment le vCenter arrivent-il \u00e0 jouer sur les tensions du processeur physique ? Si c’est bien de cette mani\u00e8re qu’il agit \u00bb.<\/p>\n\n\n\n Sources :<\/strong> Turbo Boost dans un environnement vSphere 7.0.3<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[15,18],"tags":[25,21],"class_list":["post-855","post","type-post","status-publish","format-standard","hentry","category-vmware","category-vsphere-7-0","tag-article","tag-vmware"],"_links":{"self":[{"href":"https:\/\/kdslabs.fr\/index.php\/wp-json\/wp\/v2\/posts\/855","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/kdslabs.fr\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/kdslabs.fr\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/kdslabs.fr\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/kdslabs.fr\/index.php\/wp-json\/wp\/v2\/comments?post=855"}],"version-history":[{"count":0,"href":"https:\/\/kdslabs.fr\/index.php\/wp-json\/wp\/v2\/posts\/855\/revisions"}],"wp:attachment":[{"href":"https:\/\/kdslabs.fr\/index.php\/wp-json\/wp\/v2\/media?parent=855"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/kdslabs.fr\/index.php\/wp-json\/wp\/v2\/categories?post=855"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/kdslabs.fr\/index.php\/wp-json\/wp\/v2\/tags?post=855"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Pour trouver ces 48 Ghz il faut se baser sur la formule suivante :<\/p>\n\n\n\n
Spoiler<\/strong>: Oui, mais il ne fait pas tout.<\/p>\n\n\n\n![\"\"](\"https:\/\/kdslabs.fr\/wp-content\/uploads\/2023\/04\/iDRAC-Turbo-Mode-pt1-1024x337.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/kdslabs.fr\/wp-content\/uploads\/2023\/04\/iDRAC-Turbo-Mode-pt2-1024x442.png\")
<\/figure>\n\n\n\nCharge d\u2019une VM sous OCCT avec 16 vCPU \/ 128 Go RAM<\/u><\/h4>\n\n\n\n
![\"\"](\"https:\/\/kdslabs.fr\/wp-content\/uploads\/2023\/04\/Screenshot-2023-04-24-094324-1024x288.png\")
<\/figure>\n\n\n\nCharge de 3 VMs 16 vCPU \/ 128 Go RAM sous OCCT<\/u><\/h4>\n\n\n\n
![\"\"](\"https:\/\/kdslabs.fr\/wp-content\/uploads\/2023\/04\/Picture4-1024x438.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/kdslabs.fr\/wp-content\/uploads\/2023\/04\/Picture5-1024x323.png\")
<\/figure>\n\n\n\n
En fait sur son performance chart il affiche un max de 107.71 Ghz ce qui correspond \u00e0 18 c\u0153urs physiques * 3 Ghz de fr\u00e9quence * 2 sockets = ~108Ghz.<\/p>\n\n\n\n![\"\"](\"https:\/\/kdslabs.fr\/wp-content\/uploads\/2023\/04\/Picture6-1024x403.png\")
<\/figure>\n\n\n\n\n
![\"\"](\"https:\/\/kdslabs.fr\/wp-content\/uploads\/2023\/04\/Picture7-1-1024x196.png\")
<\/figure>\n\n\n\nSaturation de l\u2019ESXi avec 4 VMs :<\/u><\/h4>\n\n\n\n
![\"\"](\"https:\/\/kdslabs.fr\/wp-content\/uploads\/2023\/04\/Picture8-1024x325.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/kdslabs.fr\/wp-content\/uploads\/2023\/04\/Picture9-1024x231.png\")
<\/figure>\n\n\n\n
<\/strong><\/p>\n\n\n\nSaturation d\u2019un ESXi avec 5 VMs.<\/u><\/h4>\n\n\n\n
![\"\"](\"https:\/\/kdslabs.fr\/wp-content\/uploads\/2023\/04\/Picture10-1-1024x350.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/kdslabs.fr\/wp-content\/uploads\/2023\/04\/Picture11-1024x246.png\")
<\/figure>\n\n\n\nConclusion :<\/u><\/h4>\n\n\n\n
Processeur Intel\u00ae Xeon\u00ae Gold 6354
https:\/\/ark.intel.com\/content\/www\/fr\/fr\/ark\/products\/212460\/intel-xeon-gold-6354-processor-39m-cache-3-00-ghz.html<\/a>
Testing CPU Max Turbo Boost Frequency in ESXi (80610)
https:\/\/kb.vmware.com\/s\/article\/80610<\/a>
Troubleshooting a virtual machine that has stopped responding: VMM and Guest CPU usage comparison (1017926)
https:\/\/kb.vmware.com\/s\/article\/1017926<\/a>
Why is %WAIT so high in esxtop?
https:\/\/www.yellow-bricks.com\/2012\/07\/17\/why-is-wait-so-high\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"