A l’occasion de l’intégration récente de nouvelles machines de guerre ESXi sur notre ferme de production, nous avons été confrontés à des statistiques vraiment bizarres sur vRealize Operations. En effet, les graphiques faisaient apparaître une contention CPU très élevée, alors que l’ajout de ces hosts devait justement réduire la charge globale du cluster et mécaniquement faire baisser cette contention…
Petit récit d’une analyse éclairée par quelques recherches Google ;)
Plus précisément, nous nous sommes rendu compte que les contentions CPU apparaissaient uniquement sur les nouvelles machines et pas (ou peu) sur les anciens membres du cluster. Vous pouvez voir sur ce graphique vROps le niveau très élevé atteint récemment, plus de 30% sur une seule machine !
J’ai commencé à investiguer la chose, car cela n’avait pas vraiment de sens : le serveur que j’ai pris pour cible n’hébergeait que 6 VMs de 4 vCPU alors que le host est un bi-Xeon E5-2680 avec pas moins de 28 coeurs physiques ! Autant dire qu’il y avait largement la place et la puissance pour contenter tout le monde. En creusant un peu via esxtop (le swiss-army-knife de tout admin VMware), j’ai constaté d’abord que le %CPU Ready restait très bas à moins de 0,25% en moyenne, ce qui était finalement de bonne augure et laissait entendre que malgré ces statistiques inquiétantes, les VMs semblaient parfaitement servies par l’hyperviseur. Mais alors, d’où venait cette “contention” si élevée sur vROps ??
Après quelques recherches sur le Net, je suis tombé sur plusieurs fils de discussion, notamment sur les communautés VMware (voir par exemple ici), qui parlaient précisément de ce problème et pointaient du doigt une autre valeur, non affichée par défaut : %LAT_C. Bizarrement, la définition de VMware est très proche, voir équivalente à %RDY … en tout cas en première approximation : LAT_C, ou Latency_CPU, est le pourcentage de temps pendant lequel le processus ou la VM attend l’accès au CPU mais ne l’obtient pas pour cause de contention… bien avancé, du coup, le gars … Certains constataient donc que ce %LAT_C était extrêmement élevé (il est accessible via esxtop en ajoutant l’option “I = SUMMARY STATS” à la vue CPU). Et force est de constater que c’était aussi le cas chez nous :
Visiblement, ce %LAT_C abracadabrantesque est souvent du au choix du mode de gestion de l’énergie des CPUs mis en oeuvre sur la machine ! Lorsque vous êtes en mode “dynamique” cet indicateur s’envole très régulièrement, sans doute à cause d’une gestion dynamique des fréquences de fonctionnement des CPUs et non directement maîtrisée par ESXi. En l’occurrence, en modifiant ce paramétrage dans le BIOS de la machine (ce qui, sur nos HP, se fait directement dans iLO et est pris en compte sans reboot), dans la seconde qui a suivi, le %LAT_C est retombé quasiment à zéro, éliminant du même coup les niveaux de contentions constatés sur vROps :
Il faut savoir que sur les machines récentes, disposant de processeurs capable de faire grandement varier leur fréquence de fonctionnement en fonction de la charge, la plupart des constructeurs implémentent dans les BIOS un paramètre spécifique à ce sujet, comme c’est le cas chez HP :
… Si vous forcez la machine en mode “high performance” ou si vous laissez le choix à ESXi avec l’option “OS Control Mode” (à vérifier), vous résolvez la plupart du temps les problèmes statistiques associés au fameux %LAT_C. En tout cas, sans en avoir aujourd’hui une explication parfaitement claire de la part de VMware, c’est ce que beaucoup constatent.
Au final, difficile de dire si cette “contention affichée” avait un quelconque un impact réel sur les performances de nos VMs, mais c’est toujours plus sympa d’avoir une courbe bien raisonnable et bien sage, après l’opération coup-de-poing de modification des paramètres BIOS de toutes les machines impliquées, voyez plutôt :
