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 ?
Source : Server Fault,)