Est-ce une bonne pratique de désactiver SpeedStep pour les hôtes Hyper-V ?

Windows Server & IT Pro Hyper-V & Virtualisation
1

J’analyse un problème où les performances des charges de travail liées au CPU à l’intérieur des machines virtuelles sont souvent (pas toujours) bien en dessous de ce que nous attendrions en fonction du matériel sous-jacent.

Nous utilisons Hyper-V sur Windows Server 2012 R2. Le serveur a un double Intel Xeon E5-2643 v2 @ 3,50 GHz.

Voici quelques chiffres qui semblent pertinents :

  • Hyper-V Hypervisor Logical Processor, % Total Run Time, Instance _Total : Moyenne 20%

  • Hyper-V Hypervisor Virtual Processor, CPU Wait Time Per Dispatch, Instance _Total : Moyenne 20000 (ce nombre semble être totalement dans les limites acceptables, donc il ne semble pas que l’hyperviseur doive « voler » du CPU virtuel pour planifier du temps sur les processeurs logiques d’une autre VM ; semble se traduire par une surcharge de 2%)

  • Hyper-V Hypervisor Logical Processor, % of Max Frequency, Instance _Total : Moyenne 34%

  • L’outil CPU-Z montre la plupart du temps environ 1200 MHz pour le Core #0 des deux processeurs (correspond à peu près au % de fréquence max rapporté par le moniteur de performances)

Sur un poste de travail avec seulement quelques cœurs, la vitesse du cœur augmente immédiatement dès qu’une activité liée au CPU démarre.

Sur nos hôtes Hyper-V cependant, la vitesse du cœur semble n’augmenter que si la charge globale du système semble être élevée pendant quelques secondes. Maintenant, par exemple, si vous avez une VM avec 4 CPU virtuels sur un total de 24 physiques (avec l’Hyper-Threading activé), et que cette VM a besoin de puissance CPU et que le gestionnaire de tâches à l’intérieur de la VM montre près de 100% d’utilisation CPU, la plupart du temps la fréquence d’horloge du CPU physique n’augmentera pas et les performances seront mauvaises.

Évidemment, c’est un comportement indésirable. Pensez à un serveur de base de données qui a besoin de 3 fois plus de temps pour répondre à une requête parce que le serveur n’a pas « assez » de charge pour augmenter la fréquence du CPU. Cela n’a aucun sens.

J’ai trouvé un article de blog décrivant exactement le même comportement pour VMWare et les lames Cisco, de 2011. Je n’ai trouvé d’informations à ce sujet nulle part ailleurs.

J’ai effectivement réussi à me débarrasser de ce comportement en passant au plan d’alimentation Windows « Hautes performances » dans powercfg.cpl, au prix d’environ 30% de consommation d’énergie supplémentaire. J’obtiens en fait de meilleures performances plus constantes et le moniteur de performances montre des chiffres de charge plus bas.

(Sur un ancien serveur, j’ai trouvé un paramètre supplémentaire « Gestion de l’alimentation du processeur | État minimum du processeur » qui pouvait être réglé à 100% sans désactiver toutes les autres options d’économie d’énergie. Les nouveaux ne montrent que « politique de refroidissement du système » qui est sur « Actif » même pour le plan « Équilibré », donc ma seule option était de choisir « Hautes performances ».)

Est-ce vraiment la meilleure pratique pour les hôtes Hyper-V, ou y a-t-il une autre solution de contournement ? Si SpeedStep est vraiment un problème, je me demande pourquoi ils l’intègrent même dans les CPU serveur et l’activent par défaut et pourquoi je n’ai jamais lu à propos de ce paramètre dans un guide de configuration Hyper-V ?

2

Après quelques recherches supplémentaires, il semble que ce soit un problème général avec les CPU serveur modernes, même sans rapport avec la virtualisation, et les principaux fabricants de serveurs ainsi que les éditeurs de logiciels comme Microsoft et VMWare livrent leurs produits avec des paramètres par défaut qui limitent artificiellement les performances de votre CPU. J’ai encore du mal à y croire.

La solution pour quiconque souhaite avoir un accès instantané à la pleine puissance CPU par cœur sans que tous les cœurs soient occupés d’abord, est de désactiver l’économie d’énergie (Intel SpeedStep/EIST ou AMD Cool’n’Quiet). Selon vos paramètres BIOS, cela peut être contrôlé au niveau de l’OS (comme dans Windows powercfg.cpl plan « Hautes performances »), ou via le BIOS, auquel cas le paramètre de l’OS est grisé.

Brent Ozar a écrit à ce sujet (“SQL Server on Power-Saving CPUs? Not So Fast.”) en 2011 :

Au cours des dernières semaines, j’ai vu plusieurs cas où des mises à niveau de serveurs ont entraîné de moins bonnes performances, et l’un des facteurs clés a été les CPU en régime réduit. En théorie, les serveurs devraient augmenter la puissance en fonction de la demande, mais en réalité, c’est rarement le cas. Les fabricants de serveurs cachent des paramètres d’économie d’énergie dans le BIOS, et Windows Server est livré avec une option d’économie d’énergie par défaut qui réduit la fréquence du CPU bien trop souvent.

Microsoft dit dans le KB2207548 :

Dans certains cas, vous pouvez constater une dégradation globale des performances sur une machine Windows Server 2008 R2 lorsqu’elle fonctionne avec le plan d’alimentation par défaut (Équilibré). Le problème peut survenir indépendamment de la plateforme et peut se manifester dans des environnements natifs et virtuels. La dégradation des performances peut augmenter le temps de réponse moyen pour certaines tâches et causer des problèmes de performances avec les applications gourmandes en CPU. […]
Ce problème peut survenir si les paramètres des options d’alimentation sont définis sur Équilibré. Par défaut, Windows Server 2008 R2 définit le plan d’alimentation Équilibré (recommandé)

Un correctif est disponible pour Win2008R2, et une mise à jour du BIOS est recommandée, mais comme c’est un problème qui persiste avec Win2012R2, il semble qu’il n’y ait pas moyen de contourner la seconde recommandation, le plan « Hautes performances ».

Un problème avec des symptômes similaires est décrit dans le KB2534356 qui offre également un correctif pour Win2008R2 uniquement. Donc pour moi, seule la solution de contournement habituelle s’applique (plan Hautes performances), mais il semble qu’un correctif pourrait être possible à l’avenir. (Cela fonctionne très bien sur les CPU de bureau, donc je ne comprends pas pourquoi ce ne serait pas possible sur le serveur.)

Je mettrai à jour cette réponse au cas où je trouverais une meilleure solution (ou bien sûr je changerai la réponse acceptée si quelqu’un d’autre publie une solution).

Je me demande toujours si EC2 ou Azure pourraient avoir le même problème (dans ce cas, vous ne pourriez rien y faire puisque vous avez besoin du contrôle de l’hôte, changer le paramètre dans la VM n’aura aucun effet).

Quelques références supplémentaires :