Si vous administrez une infrastructure virtuelle basée sur VMware vSphere (ou toute autre pile technologique), vous entendez probablement fréquemment des plaintes des utilisateurs : « La machine virtuelle est lente ! ». Dans ce cycle d'articles, j'examinerai les métriques de performances et expliquerai ce qui « ralentit » et pourquoi, ainsi que comment y remédier.
Je vais considérer les aspects suivants des performances des machines virtuelles :
- CPU,
- RAM,
- DISQUE,
- Réseau.
Je commencerai par le CPU.
Pour analyser les performances, nous aurons besoin :
- VCenter Performance Counters – compteurs de performance, dont les graphiques peuvent être consultés via le vSphere Client. Les informations sur ces compteurs sont disponibles dans toutes les versions du client (client « lourd » en C#, client web en Flex et client web en HTML5). Dans ces articles, nous utiliserons des captures d'écran du client C#, simplement parce qu'elles rendent mieux en miniature :)
- ESXTOP – un outil lancé depuis la ligne de commande d'ESXi. Il permet d'obtenir les valeurs des compteurs de performance en temps réel ou d'exporter ces valeurs sur une période déterminée dans un fichier .csv pour une analyse ultérieure. Je vais expliquer cet outil plus en détail et fournir quelques liens utiles vers la documentation et des articles sur le sujet.
Un peu de théorie
Dans ESXi, chaque vCPU (cœur de la machine virtuelle) est géré par un processus distinct – world dans la terminologie VMware. Il existe également des processus de service, mais du point de vue de l'analyse de performance des VMs, ils sont moins intéressants.
Un processus dans ESXi peut se trouver dans l'un des quatre états :
- Exécution – le processus effectue un travail utile.
- Attente – le processus n'effectue aucun travail (inactif) ou attend une entrée/sortie.
- Stop – un état qui survient dans les machines virtuelles multicoeurs. Il se produit lorsque le planificateur de CPU de l'hyperviseur (ESXi CPU Scheduler) n'est pas en mesure de planifier l'exécution simultanée de tous les cœurs actifs de la machine virtuelle sur les cœurs physiques du serveur. Dans le monde physique, tous les cœurs du processeur fonctionnent en parallèle, le système d'exploitation invité à l'intérieur de la VM s'attend à un comportement similaire, donc l'hyperviseur doit ralentir les cœurs de la VM qui ont la capacité de terminer un cycle plus rapidement. Dans les versions modernes d'ESXi, le planificateur de CPU utilise un mécanisme appelé co-planification détendue : l'hyperviseur considère l'écart entre le cœur « le plus rapide » et le cœur « le plus lent » de la machine virtuelle (skew). Si l'écart dépasse un certain seuil, le cœur « rapide » passe en état de costop. Si les cœurs de la VM passent beaucoup de temps dans cet état, cela peut entraîner des problèmes de performance.
- Prêt – un processus passe dans cet état lorsque l'hyperviseur n'a pas la possibilité d'allouer des ressources pour son exécution. Des valeurs élevées de ready peuvent provoquer des problèmes de performance de la VM.
Principaux compteurs de performance CPU de la machine virtuelle
Utilisation CPU, %. Montre le pourcentage d'utilisation du CPU sur une période donnée.
Comment analyser ? Si la VM utilise de manière stable le CPU à 90 % ou qu'il y a des pics allant jusqu'à 100 %, nous avons des problèmes. Ces problèmes peuvent se manifester non seulement par un fonctionnement « lent » de l'application à l'intérieur de la VM, mais aussi par l'inaccessibilité de la VM sur le réseau. Si le système de surveillance montre que la VM se déconnecte périodiquement, faites attention aux pics sur le graphique d'utilisation du CPU.
Il existe une alarme standard qui montre la charge CPU de la machine virtuelle :
Que faire ? Si l'utilisation du CPU de la VM dépasse constamment, il peut être judicieux d'augmenter le nombre de vCPU (malheureusement, ce n'est pas toujours efficace) ou de déplacer la VM sur un serveur avec des processeurs plus performants.
Utilisation du CPU en Mhz
Dans les graphiques sur vCenter, l'utilisation en % ne peut être consultée que pour l'ensemble de la machine virtuelle, il n'y a pas de graphiques pour des cœurs séparés (dans Esxtop, les valeurs en % par cœur existent). Pour chaque cœur, l'utilisation en MHz peut être consultée.
Comment analyser ? Il arrive qu'une application ne soit pas optimisée pour une architecture multicœur : elle utilise à 100 % un seul cœur pendant que les autres restent inactifs. Par exemple, avec les paramètres par défaut de sauvegarde, MS SQL démarre le processus uniquement sur un cœur. En fin de compte, la sauvegarde est ralentie non pas par une lenteur des disques (c'est ce que l'utilisateur a initialement signalé), mais parce que le processeur est débordé. Le problème a été résolu en modifiant les paramètres : la sauvegarde a commencé à s'exécuter en parallèle dans plusieurs fichiers (donc dans plusieurs processus).
Exemple de charge inégale des cœurs.
Il peut également y avoir une situation (comme sur le graphique ci-dessus) où les cœurs sont chargés de manière inégale et où certains d'entre eux présentent des pics à 100 %. Tout comme lorsque seul un cœur est chargé, l'alarme concernant l'utilisation CPU ne se déclenchera pas (elle est basée sur l'ensemble de la VM), mais des problèmes de performance seront présents.
Que faire ? Si le logiciel dans la machine virtuelle charge les cœurs de manière inégale (n'utilisant qu'un seul cœur ou une partie des cœurs), il n'est pas utile d'augmenter leur nombre. Dans ce cas, il est préférable de déplacer la VM vers un serveur avec des processeurs plus performants.
Vous pouvez également essayer de vérifier les paramètres de consommation d'énergie dans le BIOS du serveur. De nombreux administrateurs activent dans le BIOS le mode Haute Performance et désactivent ainsi les technologies d'économie d'énergie C-states et P-states. Les processeurs Intel modernes utilisent la technologie Turbo Boost, qui augmente la fréquence des cœurs individuels du processeur au détriment d'autres cœurs. Mais elle ne fonctionne que si les technologies d'économie d'énergie sont activées. Si nous les désactivons, le processeur ne peut pas réduire la consommation énergétique des cœurs qui ne sont pas sollicités.
VMware recommande de ne pas désactiver les technologies d'économie d'énergie sur les serveurs, mais de choisir des modes qui laissent le contrôle de la consommation d'énergie au hyperviseur. De plus, dans les paramètres de consommation d'énergie de l'hyperviseur, il faut sélectionner Haute Performance.
Si vous avez dans votre infrastructure des VM (ou des cœurs de VM) qui nécessitent une fréquence CPU élevée, un réglage correct de la consommation d'énergie peut améliorer considérablement leurs performances.
CPU Ready (Prêt du CPU)
Si le noyau de la machine virtuelle (vCPU) est en état Ready, il n'effectue aucun travail utile. Cet état survient lorsque l'hyperviseur ne trouve pas de noyau physique libre sur lequel il peut assigner le processus vCPU de la machine virtuelle.
Comment analyser ? En général, si les noyaux de la machine virtuelle sont en état Ready plus de 10 % du temps, vous remarquerez des problèmes de performance. En d'autres termes, plus de 10 % du temps, la machine virtuelle attend la disponibilité des ressources physiques.
Dans vCenter, vous pouvez voir deux compteurs liés à CPU Ready :
- Readiness,
- Ready.
Les valeurs des deux compteurs peuvent être consultées à la fois pour l'ensemble de la machine virtuelle et pour des noyaux individuels.
Readiness affiche la valeur immédiatement en pourcentage, mais uniquement en temps réel (données de la dernière heure, intervalle de mesure de 20 secondes). Ce compteur est préférable à utiliser uniquement pour détecter des problèmes « à chaud ».
Les valeurs du compteur Ready peuvent également être consultées dans une perspective historique. Cela est utile pour établir des modèles et pour une analyse plus approfondie du problème. Par exemple, si une machine virtuelle commence à avoir des problèmes de performance à un moment donné, il est possible de comparer les intervalles de valeur élevée de CPU Ready avec la charge générale du serveur sur lequel cette machine virtuelle fonctionne, et de prendre des mesures pour réduire la charge (si DRS n'a pas réussi).
Ready, contrairement à Readiness, n'est pas montré en pourcentage, mais en millisecondes. C'est un compteur de type Somme, ce qui signifie qu'il indique combien de temps, pendant la période de mesure, le noyau de la machine virtuelle a été en état Ready. Cette valeur peut être convertie en pourcentage par une formule simple :
(valeur de sommation CPU ready / (intervalle de mise à jour par défaut du graphique en secondes * 1000)) * 100 = CPU ready %
Par exemple, pour la machine virtuelle sur le graphique ci-dessous, la valeur maximale de Ready pour l'ensemble de la machine virtuelle sera la suivante :
Lorsque vous calculez la valeur de Ready en pourcentage, il est important de prêter attention à deux points :
- La valeur Ready pour l'ensemble de la machine virtuelle est la somme de Ready pour les noyaux.
- L'intervalle de mesure. Pour Real-time, c'est 20 secondes, et, par exemple, sur les graphiques quotidiens, c'est 300 secondes.
Lors d'un dépannage actif, ces simples points peuvent facilement être négligés et vous pourriez perdre un temps précieux à résoudre des problèmes inexistants.
Nous calculons le Ready en fonction des données du graphique ci-dessous. (324474/(20*1000))*100 = 1622% pour l'ensemble de la VM. Si l'on regarde par cœurs, ce n'est pas si inquiétant : 1622/64 = 25% par cœur. Dans ce cas, il est assez facile de détecter le problème : la valeur Ready est irréaliste. Mais s'il s'agit de 10 à 20% pour toute la VM avec plusieurs cœurs, alors pour chaque cœur, la valeur peut être dans les limites normales.
Que faire ? Une valeur élevée de Ready indique que le serveur manque de ressources processeur pour fonctionner normalement avec les machines virtuelles. Dans cette situation, il ne reste plus qu'à réduire la surallocation CPU (vCPU:pCPU). Il est évident que cela peut être réalisé en diminuant les spécifications des VM existantes ou en migrant certaines VM vers d'autres serveurs.
Co-stop
Comment analyser ? Ce compteur a également le type Somme et se traduit en pourcentages de la même manière que Ready :
(valeur de somme de co-stop CPU / (intervalle de mise à jour par défaut du graphique en secondes * 1000)) * 100 = % de co-stop CPU
Il faut également faire attention au nombre de cœurs sur la VM et à l'intervalle de mesure.
En état de co-stop, le cœur n'exécute pas de travail utile. Avec un dimensionnement correct de la VM et une charge normale sur le serveur, le compteur de co-stop doit être proche de zéro.
Dans ce cas, la charge est clairement anormale :)
Que faire ? Si plusieurs VM avec un grand nombre de cœurs fonctionnent sur un même hyperviseur et qu'il y a une surallocation CPU, le compteur de co-stop peut augmenter, ce qui entraînera des problèmes de performance pour ces VM.
Le co-stop augmentera également si les cœurs actifs d'une VM utilisent des threads sur un même cœur physique du serveur avec hyper-threading activé. Cela peut se produire, par exemple, si la VM a plus de cœurs que ceux physiquement disponibles sur le serveur où elle fonctionne, ou si pour la VM l'option 'preferHT' est activée. On peut lire à propos de ce réglage. .
Pour éviter les problèmes de performance de la VM dus à un co-stop élevé, choisissez la taille de la VM conformément aux recommandations du fournisseur de logiciels qui fonctionne sur cette VM et aux capacités du serveur physique sur lequel la VM est exécutée.
N'ajoutez pas de cœurs en surplus, cela peut provoquer des problèmes de performance non seulement pour la VM elle-même, mais aussi pour ses voisines sur le serveur.
D'autres métriques utiles du CPU
Exécution – combien de temps (ms) pendant la période de mesure le vCPU a été en état de RUN, c'est-à-dire qu'il a effectivement effectué un travail utile.
Idle – combien de temps (ms) au cours de la période de mesure le vCPU a été inactif. Des valeurs élevées d'Idle ne posent pas de problème, cela signifie simplement que le vCPU n'avait « rien à faire ».
Attente – combien de temps (ms) au cours de la période de mesure le vCPU a été en état d'attente. Comme ce compteur inclut l'IDLE, des valeurs élevées de Wait ne signent pas non plus un problème. Cependant, si l'IDLE est bas avec un Wait élevé, cela signifie que la VM attendait la fin des opérations d'entrée/sortie. Cela peut indiquer un problème de performance du disque dur ou de certains appareils virtuels de la VM.
Max limité – combien de temps (ms) au cours de la période de mesure le vCPU a été en état Ready en raison d'une limite de ressources définie. Si la performance est inexplicablement basse, il est utile de vérifier la valeur de ce compteur et la limite CPU dans les paramètres de la VM. Il se peut que des limites soient effectivement appliquées à la VM sans que vous le sachiez. Par exemple, cela se produit lorsque la VM a été clonée à partir d'un modèle où une limite de CPU était définie.
Swap wait – combien de temps pendant la période de mesure le vCPU a attendu une opération avec VMkernel Swap. Si les valeurs de ce compteur sont supérieures à zéro, alors la VM rencontre certainement des problèmes de performance. Nous parlerons plus en détail de SWAP dans l'article sur les compteurs de mémoire vive.
ESXTOP
Si les compteurs de performance dans vCenter sont bons pour analyser les données historiques, une analyse rapide du problème est mieux réalisée dans ESXTOP. Ici, toutes les valeurs sont fournies telles quelles (pas besoin de traduire), et la période de mesure minimale est de 2 secondes.
L'écran ESXTOP pour le CPU est appelé en appuyant sur la touche « c » et ressemble à ceci :
Pour plus de commodité, vous pouvez ne garder que les processus des machines virtuelles en appuyant sur Shift-V.
Pour voir les métriques pour des cœurs individuels de la VM, appuyez sur « e » et entrez le GID de la VM qui vous intéresse (30919 sur la capture d'écran ci-dessous) :
Je vais brièvement parcourir les colonnes qui sont présentées par défaut. Des colonnes supplémentaires peuvent être ajoutées en appuyant sur « f ».
NWLD (Number of Worlds) – le nombre de processus dans le groupe. Pour développer le groupe et voir les métriques pour chaque processus (par exemple, pour chaque cœur d'une VM multicoeur), appuyez sur « e ». Si le groupe a plus d'un processus, les valeurs de métriques pour le groupe sont égales à la somme des métriques des processus individuels.
%USED – combien de cycles CPU le serveur utilise pour le processus ou le groupe de processus.
%RUN – combien de temps durant la période de mesure le processus a été en état de RUN, c'est-à-dire a exécuté un travail utile. Diffère de %USED en ce sens qu'il ne prend pas en compte l'hyper-threading, la mise à l'échelle de la fréquence et le temps passé sur des tâches système (%SYS).
%SYS – temps passé sur des tâches système, par exemple : le traitement des interruptions, les opérations d'entrée/sortie, la gestion du réseau, etc. La valeur peut être élevée si la VM a beaucoup d'entrées/sorties.
%OVRLP – combien de temps le cœur physique, sur lequel le processus de la VM s'exécute, a été occupé par des tâches d'autres processus.
Ces métriques sont liées entre elles de la manière suivante :
%USED = %RUN + %SYS — %OVRLP.
En général, la métrique %USED est plus informative.
%WAIT – combien de temps durant la période de mesure le processus a été en état d'attente. Inclut l'IDLE.
%IDLE – combien de temps durant la période de mesure le processus a été en état d'IDLE.
%SWPWT – combien de temps durant la période de mesure le vCPU a attendu une opération avec le VMkernel Swap.
%VMWAIT – combien de temps durant la période de mesure le vCPU a été en état d'attente d'un événement (habituellement d'entrée/sortie). Il n'y a pas de compteur similaire dans vCenter. Des valeurs élevées indiquent des problèmes d'entrée/sortie sur la VM.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Si la VM n'utilise pas le VMkernel Swap, lors de l'analyse des problèmes de performance, il est judicieux de se concentrer sur %VMWAIT, car cette métrique ne prend pas en compte le temps où la VM ne faisait rien (%IDLE).
%RDY – combien de temps durant la période de mesure le processus a été en état de Ready.
%CSTP – combien de temps durant la période de mesure le processus a été en état de costop.
%MLMTD – combien de temps durant la période de mesure le vCPU a été en état de Ready en raison d'une limite de ressources fixée.
%WAIT + %RDY + %CSTP + %RUN = 100% – le cœur de la VM est toujours dans l'un de ces quatre états.
CPU sur l'hyperviseur
Dans vCenter, il existe également des compteurs de performance CPU pour l'hyperviseur, mais ils n'offrent rien d'intéressant – il s'agit simplement de la somme des compteurs de toutes les VM sur le serveur.
Il est plus pratique d'observer l'état du CPU sur le serveur à l'onglet Résumé :
Pour le serveur, comme pour la machine virtuelle, il existe une Alarme standard :
En cas de forte charge sur le CPU du serveur, les VM fonctionnant dessus commencent à rencontrer des problèmes de performance.
Dans ESXTOP, les données de charge du CPU du serveur sont présentées en haut de l'écran. En plus de la charge standard du CPU, qui est peu informative pour les hyperviseurs, il y a trois autres métriques :
CORE UTIL(%) – charge du cœur physique du serveur. Ce compteur indique combien de temps pendant la période de mesure le cœur a effectué du travail.
PCPU UTIL(%) – si l'hyper-threading est activé, chaque cœur physique a deux threads (PCPU). Cette métrique montre combien de temps chaque thread a effectué du travail.
PCPU USED(%) – c'est la même chose que PCPU UTIL(%), mais prend en compte le frequency scaling (soit la réduction de la fréquence du cœur pour économiser de l'énergie, soit l'augmentation de la fréquence du cœur grâce à la technologie Turbo Boost) et l'hyper-threading.
PCPU_USED% = PCPU_UTIL% * fréquence efficace du cœur / fréquence nominale du cœur.
Sur cette capture d'écran, pour certains cœurs, en raison du fonctionnement de Turbo Boost, la valeur USED dépasse 100%, car la fréquence du cœur est supérieure à la nominale.
Quelques mots sur la façon dont l'hyper-threading est pris en compte. Si les processus s'exécutent 100% du temps sur les deux threads du cœur physique du serveur, tout en étant à la fréquence nominale, alors :
- CORE UTIL pour le cœur sera de 100%,
- PCPU UTIL pour les deux threads sera de 100%,
- PCPU USED pour les deux threads sera de 50%.
Si les deux threads n'ont pas fonctionné 100% du temps pendant la période de mesure, alors pendant les périodes où les threads ont fonctionné en parallèle, PCPU USED pour les cœurs est divisé par deux.
Dans ESXTOP, il y a également un écran avec les paramètres de consommation d'énergie du CPU du serveur. Ici, vous pouvez voir si le serveur utilise des technologies d'économie d'énergie : C-states et P-states. Appuyé sur la touche « p » :
Problèmes de performance standard du CPU
Enfin, je vais passer en revue les raisons typiques des problèmes de performance du CPU de la VM et donner quelques conseils pour résoudre ces problèmes :
Il manque de fréquence d'horloge au cœur. S'il n'est pas possible de transférer la VM sur des cœurs plus performants, vous pouvez essayer de modifier les paramètres de consommation d'énergie pour que Turbo Boost fonctionne plus efficacement.
Saisonnage incorrect de la VM (trop de / peu de cœurs). Si vous mettez peu de cœurs, la charge CPU de la VM sera élevée. Si vous en mettez trop, vous risquez d'avoir un co-stop élevé.
Une grande surallocation de CPU sur le serveur. Si la VM a un Ready élevé, réduisez la surallocation de CPU.
Topologie NUMA incorrecte sur de grandes VM. La topologie NUMA vue par la VM (vNUMA) doit correspondre à la topologie NUMA du serveur (pNUMA). Des diagnostics et des solutions possibles à ce problème sont décrits, par exemple, dans le livre . Si vous ne souhaitez pas approfondir et que vous n'avez pas de restrictions de licence sur le système d'exploitation installé sur la VM, créez plusieurs sockets virtuels sur la VM avec un seul cœur chacun. Vous n'en perdrez pas beaucoup 🙂
C'est tout pour le CPU. N'hésitez pas à poser des questions. Dans la prochaine partie, je parlerai de la mémoire vive.
Liens utiles
Source : habr.com
