<p>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.</p>
<p>Nous utilisons Hyper-V sur Windows Server 2012 R2. Le serveur a un double Intel Xeon E5-2643 v2 @ 3,50 GHz.</p>
<p>Voici quelques chiffres qui semblent pertinents :</p>
<ul>
<li>
<p>Hyper-V Hypervisor Logical Processor, % Total Run Time, Instance _Total : Moyenne 20%</p>
</li>
<li>
<p>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%)</p>
</li>
<li>
<p>Hyper-V Hypervisor Logical Processor, % of Max Frequency, Instance _Total : Moyenne 34%</p>
</li>
<li>
<p>L’outil CPU-Z montre la plupart du temps environ 1200 MHz pour le Core <span class="hashtag-raw">#0</span> des deux processeurs (correspond à peu près au % de fréquence max rapporté par le moniteur de performances)</p>
</li>
</ul>
<p>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.</p>
<p>Sur nos hôtes Hyper-V cependant, la vitesse du cœur semble n’augmenter que si la <strong>charge globale du système</strong> 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.</p>
<p>É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.</p>
<p>J’ai trouvé un <a href="http://blog.unidesk.com/speedstep-and-vdi-it-good-thing-not-me" rel="noopener nofollow ugc">article de blog décrivant exactement le même comportement pour VMWare et les lames Cisco</a>, de 2011. Je n’ai trouvé d’informations à ce sujet nulle part ailleurs.</p>
<p>J’ai effectivement réussi à me débarrasser de ce comportement en passant au plan d’alimentation Windows « Hautes performances » dans <code>powercfg.cpl</code>, 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.</p>
<p>(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 ».)</p>
<p>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 ?</p>
<hr>
<p><em>Source : <a href="http://blog.unidesk.com/speedstep-and-vdi-it-good-thing-not-me" rel="noopener nofollow ugc">Server Fault</a>,)</em></p>
