Si vous administrez une infrastructure virtuelle basée sur VMware vSphere (ou toute autre pile technologique), vous entendez probablement souvent des plaintes d'utilisateurs : « La machine virtuelle est lente ! Dans cette série d'articles, j'analyserai les mesures de performances et vous expliquerai quoi et pourquoi cela ralentit et comment m'assurer qu'il ne ralentit pas.
Je considérerai les aspects suivants des performances de la machine virtuelle :
- CPU,
- RAM,
- DISQUE,
- Réseau.
Je vais commencer par le processeur.
Pour analyser les performances, nous aurons besoin de :
- Compteurs de performances vCenter – des compteurs de performances dont les graphiques peuvent être visualisés via vSphere Client. Les informations sur ces compteurs sont disponibles dans n'importe quelle version 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#, uniquement parce qu'elles sont plus belles en miniature :)
- ESXTOP – un utilitaire qui s'exécute à partir de la ligne de commande ESXi. Avec son aide, vous pouvez obtenir les valeurs des compteurs de performances en temps réel ou télécharger ces valeurs pendant une certaine période dans un fichier .csv pour une analyse plus approfondie. Ensuite, je vous en dirai plus sur cet outil et vous fournirai plusieurs liens utiles vers de la documentation et des articles sur le sujet.
Un peu de théorie
Dans ESXi, un processus distinct – monde dans la terminologie VMware – est responsable du fonctionnement de chaque vCPU (virtual machine core). Il existe également des processus de service, mais du point de vue de l'analyse des performances des VM, ils sont moins intéressants.
Un processus dans ESXi peut être dans l'un des quatre états suivants :
- Courir – le processus effectue un travail utile.
- Attendez – le processus n’effectue aucun travail (inactif) ou attend une entrée/sortie.
- Coût – une condition qui se produit dans les machines virtuelles multicœurs. Cela se produit lorsque le planificateur de processeur de l'hyperviseur (ESXi CPU Scheduler) ne peut pas planifier l'exécution simultanée de tous les cœurs de machine virtuelle actifs sur les cœurs de serveur physique. Dans le monde physique, tous les cœurs de processeur fonctionnent en parallèle, le système d'exploitation invité à l'intérieur de la VM s'attend à un comportement similaire, l'hyperviseur doit donc ralentir les cœurs de la VM qui ont la capacité de terminer leur cycle d'horloge plus rapidement. Dans les versions modernes d'ESXi, le planificateur de processeur utilise un mécanisme appelé co-planification décontractée : l'hyperviseur considère l'écart entre le cœur de la machine virtuelle « le plus rapide » et le « le plus lent » (skew). Si l'écart dépasse un certain seuil, le noyau rapide entre dans l'état costop. Si les cœurs de VM passent beaucoup de temps dans cet état, cela peut entraîner des problèmes de performances.
- Prêt à fonctionner – le processus entre dans cet état lorsque l'hyperviseur est incapable d'allouer des ressources pour son exécution. Des valeurs prêtes élevées peuvent entraîner des problèmes de performances de la VM.
Compteurs de performances du processeur de machine virtuelle de base
L'utilisation du processeur, %. Affiche le pourcentage d'utilisation du processeur pour une période donnée.
Comment analyser ? Si une VM utilise systématiquement le CPU à 90 % ou s'il y a des pics jusqu'à 100 %, alors nous avons des problèmes. Les problèmes peuvent s'exprimer non seulement par le fonctionnement « lent » de l'application à l'intérieur de la VM, mais également par l'inaccessibilité de la VM sur le réseau. Si le système de surveillance montre que la VM tombe périodiquement en panne, faites attention aux pics dans le graphique d'utilisation du processeur.
Il existe une alarme standard qui affiche la charge CPU de la machine virtuelle :
Que faire? Si l’utilisation du processeur d’une VM augmente constamment, vous pouvez alors envisager d’augmenter le nombre de vCPU (malheureusement, cela n’aide pas toujours) ou de déplacer la VM vers un serveur doté de processeurs plus puissants.
Utilisation du processeur en MHz
Dans les graphiques sur l'utilisation de vCenter en %, vous ne pouvez voir que l'ensemble de la machine virtuelle ; il n'y a pas de graphiques pour les cœurs individuels (dans Esxtop, il y a des valeurs en % pour les cœurs). Pour chaque cœur, vous pouvez voir l'utilisation en MHz.
Comment analyser ? Il arrive qu'une application ne soit pas optimisée pour une architecture multicœur : elle n'utilise qu'un seul cœur à 100 %, et les autres sont inactifs sans charge. Par exemple, avec les paramètres de sauvegarde par défaut, MS SQL démarre le processus sur un seul cœur. En conséquence, la sauvegarde ralentit non pas à cause de la lenteur des disques (c'est ce dont l'utilisateur s'est initialement plaint), mais parce que le processeur ne peut pas faire face. 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 (respectivement dans plusieurs processus).
Un exemple de charge inégale sur les noyaux.
Il existe également une situation (comme dans le graphique ci-dessus) où les cœurs sont chargés de manière inégale et certains d'entre eux ont des pics à 100 %. Comme pour le chargement d'un seul cœur, l'alarme d'utilisation du processeur ne fonctionnera pas (c'est pour l'ensemble de la VM), mais il y aura des problèmes de performances.
Que faire? Si le logiciel d'une machine virtuelle charge les cœurs de manière inégale (n'utilise qu'un seul cœur ou une partie des cœurs), cela n'a aucun sens d'augmenter leur nombre. Dans ce cas, il est préférable de déplacer la VM vers un serveur doté de processeurs plus puissants.
Vous pouvez également essayer de vérifier les paramètres de consommation d'énergie dans le BIOS du serveur. De nombreux administrateurs activent le mode Hautes performances dans le BIOS 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 de processeur individuels au détriment des autres cœurs. Mais cela ne fonctionne que lorsque les technologies d'économie d'énergie sont activées. Si nous les désactivons, le processeur ne peut pas réduire la consommation électrique des cœurs non chargés.
VMware recommande de ne pas désactiver les technologies d'économie d'énergie sur les serveurs, mais de choisir des modes qui laissent autant que possible la gestion de l'énergie à l'hyperviseur. Dans ce cas, dans les paramètres de consommation électrique de l'hyperviseur, vous devez sélectionner Hautes performances.
Si votre infrastructure comporte des machines virtuelles individuelles (ou des cœurs de machine virtuelle) qui nécessitent une fréquence de processeur accrue, un ajustement correct de la consommation électrique peut améliorer considérablement leurs performances.
Prêt pour le processeur
Si le cœur de la VM (vCPU) est à l'état Prêt, il n'effectue aucun travail utile. Cette condition se produit lorsque l'hyperviseur ne trouve pas de cœur physique libre auquel le processus vCPU de la machine virtuelle peut être attribué.
Comment analyser ? En règle générale, si les cœurs d'une machine virtuelle sont à l'état Prêt plus de 10 % du temps, vous remarquerez des problèmes de performances. En termes simples, plus de 10 % du temps, la VM attend que les ressources physiques soient disponibles.
Dans vCenter, vous pouvez afficher 2 compteurs liés à CPU Ready :
- préparation,
- Prêt.
Les valeurs des deux compteurs peuvent être consultées à la fois pour l'ensemble de la VM et pour des cœurs individuels.
L'état de préparation affiche immédiatement la valeur sous forme de pourcentage, mais uniquement en temps réel (données de la dernière heure, intervalle de mesure de 20 secondes). Il est préférable d'utiliser ce compteur uniquement pour rechercher des problèmes « sur les talons ».
Les valeurs des compteurs prêts peuvent également être visualisées d'un point de vue historique. Ceci est utile pour établir des modèles et pour une analyse plus approfondie du problème. Par exemple, si une machine virtuelle commence à rencontrer des problèmes de performances à un certain moment, vous pouvez comparer les intervalles de la valeur CPU Ready avec la charge totale sur le serveur sur lequel cette VM est exécutée et prendre des mesures pour réduire la charge (si DRS échoue).
Prêt, contrairement à l'état de préparation, n'est pas affiché en pourcentage, mais en millisecondes. Il s'agit d'un compteur de type Summation, c'est-à-dire qu'il indique combien de temps pendant la période de mesure le cœur de la VM est resté à l'état Prêt. Vous pouvez convertir cette valeur en pourcentage à l'aide d'une formule simple :
(Valeur de somme du CPU prêt / (intervalle de mise à jour par défaut du graphique en secondes * 1000)) * 100 = % CPU prêt
Par exemple, pour la VM dans le graphique ci-dessous, la valeur maximale de Prêt pour l'ensemble de la machine virtuelle sera la suivante :
Lors du calcul du pourcentage Prêt, vous devez faire attention à deux points :
- La valeur Prêt pour l’ensemble de la VM est la somme des valeurs Prêt sur tous les cœurs.
- Intervalle de mesure. Pour le temps réel, il s'agit de 20 secondes et, par exemple, sur les graphiques journaliers, de 300 secondes.
Avec un dépannage actif, ces points simples peuvent facilement passer inaperçus et un temps précieux peut être perdu à résoudre des problèmes inexistants.
Calculons Ready en fonction des données du graphique ci-dessous. (324474/(20*1000))*100 = 1622 % pour l'ensemble de la VM. Si vous regardez les noyaux, ce n'est pas si effrayant : 1622/64 = 25 % par cœur. Dans ce cas, le problème est assez facile à repérer : la valeur Ready est irréaliste. Mais si nous parlons de 10 à 20 % pour l'ensemble de la VM avec plusieurs cœurs, alors pour chaque cœur, la valeur peut être dans la plage normale.
Que faire? Une valeur Prêt élevée indique que le serveur ne dispose pas de suffisamment de ressources processeur pour le fonctionnement normal des machines virtuelles. Dans une telle situation, il ne reste plus qu’à réduire le surabonnement par processeur (vCPU :pCPU). Évidemment, cela peut être réalisé en réduisant les paramètres des VM existantes ou en migrant une partie des VM vers d'autres serveurs.
Co-arrêt
Comment analyser ? Ce compteur est également de type Sommation et se convertit en pourcentages de la même manière que Prêt :
(Valeur de somme du co-arrêt du processeur / (intervalle de mise à jour par défaut du graphique en secondes * 1000 100)) * XNUMX = % de co-arrêt du processeur
Ici, vous devez également faire attention au nombre de cœurs sur la VM et à l'intervalle de mesure.
Dans l'état costop, le noyau n'effectue aucun travail utile. Avec la sélection correcte de la taille de la VM et la 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 machines virtuelles avec un grand nombre de cœurs s'exécutent sur un hyperviseur et qu'il y a un surabonnement sur le CPU, alors le compteur de co-stop peut augmenter, ce qui entraînera des problèmes de performances de ces machines virtuelles.
De plus, le co-stop augmentera si les cœurs actifs d’une VM utilisent des threads sur un cœur de serveur physique avec l’hyper-treading activé. Cette situation peut se produire, par exemple, si la VM a plus de cœurs que ce qui est physiquement disponible sur le serveur sur lequel elle s'exécute, ou si le paramètre « preferHT » est activé pour la VM. Vous pouvez en savoir plus sur ce paramètre .
Pour éviter les problèmes de performances de la VM dus à un co-stop élevé, sélectionnez la taille de la VM conformément aux recommandations du fabricant du logiciel qui s'exécute sur cette VM et aux capacités du serveur physique sur lequel la VM s'exécute.
N'ajoutez pas de cœurs en réserve, cela pourrait entraîner des problèmes de performances non seulement pour la VM elle-même, mais également pour ses voisines sur le serveur.
Autres mesures utiles du processeur
Courir – combien de temps (ms) pendant la période de mesure le vCPU était à l'état RUN, c'est-à-dire qu'il effectuait réellement un travail utile.
Idle – combien de temps (ms) pendant la période de mesure le vCPU est resté en état d'inactivité. Les valeurs d'inactivité élevées ne sont pas un problème, le vCPU n'avait simplement « rien à faire ».
Attendez – combien de temps (ms) pendant la période de mesure le vCPU est resté dans l'état d'attente. Étant donné que IDLE est inclus dans ce compteur, les valeurs d'attente élevées n'indiquent pas non plus un problème. Mais si Wait IDLE est faible alors que Wait est élevé, cela signifie que la VM attendait la fin des opérations d'E/S, ce qui, à son tour, peut indiquer un problème de performances du disque dur ou de tout périphérique virtuel de la VM.
Max limité – combien de temps (ms) pendant la période de mesure le vCPU est resté à l'état Prêt en raison de la limite de ressources définie. Si les performances sont inexplicablement faibles, il est alors utile de vérifier la valeur de ce compteur et la limite du CPU dans les paramètres de la VM. Les VM peuvent en effet avoir des limites dont vous n'avez pas conscience. Par exemple, cela se produit lorsqu'une VM a été clonée à partir d'un modèle sur lequel la limite de CPU a été définie.
Échange d'attente – 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 a définitivement des problèmes de performances. Nous parlerons davantage de SWAP dans l'article sur les compteurs RAM.
ESXTOP
Si les compteurs de performances dans vCenter sont efficaces pour analyser les données historiques, alors l'analyse opérationnelle du problème est mieux effectuée dans ESXTOP. Ici, toutes les valeurs sont présentées sous une forme prête à l'emploi (pas besoin de traduire quoi que ce soit) et la période de mesure minimale est de 2 secondes.
L'écran ESXTOP pour CPU est appelé avec la touche "c" et ressemble à ceci :
Pour plus de commodité, vous pouvez quitter uniquement les processus de machine virtuelle en appuyant sur Shift-V.
Pour afficher les métriques des cœurs de VM individuels, appuyez sur « e » et entrez le GID de la VM qui vous intéresse (30919 dans la capture d'écran ci-dessous) :
Permettez-moi de passer brièvement en revue les colonnes présentées par défaut. Des colonnes supplémentaires peuvent être ajoutées en appuyant sur "f".
NWLD (Nombre de mondes) – nombre de processus dans le groupe. Pour élargir le groupe et afficher les métriques de chaque processus (par exemple, pour chaque cœur d'une VM multicœur), appuyez sur « e ». S'il y a plus d'un processus dans un groupe, les valeurs des métriques du groupe sont égales à la somme des métriques des processus individuels.
%UTILISÉ – combien de cycles CPU du serveur sont utilisés par un processus ou un groupe de processus.
%COURIR – combien de temps pendant la période de mesure le processus est resté à l'état RUN, c'est-à-dire fait un travail utile. Il diffère de %USED dans le sens où il ne prend pas en compte l'hyper-threading, la mise à l'échelle des fréquences et le temps passé sur les tâches système (%SYS).
%SYS – le temps passé sur les tâches système, par exemple : traitement des interruptions, E/S, fonctionnement du réseau, etc. La valeur peut être élevée si la VM dispose d'E/S volumineuses.
%OVRLP – combien de temps le cœur physique sur lequel le processus VM s'exécute a consacré aux tâches d'autres processus.
Ces mesures sont liées les unes aux autres comme suit :
%UTILISÉ = %RUN + %SYS - %OVRLP.
Généralement, la métrique %USED est plus informative.
%ATTENDEZ – combien de temps pendant la période de mesure le processus est resté à l'état d'attente. Active IDLE.
%INACTIF – combien de temps pendant la période de mesure le processus est resté à l'état IDLE.
%SWPWT – combien de temps pendant la période de mesure le vCPU a attendu une opération avec VMkernel Swap.
%VMWAIT – combien de temps pendant la période de mesure le vCPU était en attente d'un événement (généralement des E/S). Il n'existe pas de compteur similaire dans vCenter. Des valeurs élevées indiquent des problèmes d'E/S sur la VM.
%ATTENDRE = %VMWAIT + %IDLE + %SWPWT.
Si la VM n'utilise pas VMkernel Swap, lors de l'analyse des problèmes de performances, il est conseillé de consulter %VMWAIT, car cette métrique ne prend pas en compte le moment où la VM ne faisait rien (%IDLE).
%RDY – combien de temps pendant la période de mesure le processus est resté à l'état Prêt.
%CSTP – combien de temps pendant la période de mesure le processus est resté dans l'état costop.
%MLMTD – combien de temps pendant la période de mesure le vCPU est resté à l'état Prêt en raison de la limite de ressources définie.
%WAIT + %RDY + %CSTP + %RUN = 100 % – le cœur de la VM est toujours dans l'un de ces quatre états.
CPU sur hyperviseur
vCenter dispose également de compteurs de performances CPU pour l'hyperviseur, mais ils n'ont rien d'intéressant : ils sont simplement la somme des compteurs de toutes les machines virtuelles du serveur.
Le moyen le plus pratique d'afficher l'état du processeur sur le serveur consiste à utiliser l'onglet Résumé :
Pour le serveur, ainsi que pour la machine virtuelle, il existe une alarme standard :
Lorsque la charge du processeur du serveur est élevée, les machines virtuelles qui y sont exécutées commencent à rencontrer des problèmes de performances.
Dans ESXTOP, les données de charge du processeur du serveur sont présentées en haut de l'écran. En plus de la charge CPU standard, peu informative pour les hyperviseurs, il existe trois autres métriques :
UTILITÉ DE BASE (%) – chargement du cœur du serveur physique. Ce compteur indique combien de temps le noyau a travaillé pendant la période de mesure.
PCPU UTIL(%) – si l’hyper-threading est activé, alors il y a deux threads (PCPU) par cœur physique. Cette métrique montre combien de temps chaque thread a mis pour terminer son travail.
PCPU UTILISÉ(%) – identique à PCPU UTIL(%), mais prend en compte la mise à l'échelle de fréquence (soit en réduisant la fréquence centrale à des fins d'économie d'énergie, soit en augmentant la fréquence centrale grâce à la technologie Turbo Boost) et l'hyper-threading.
PCPU_USED% = PCPU_UTIL% * fréquence de base effective / fréquence de base nominale.
Dans cette capture d'écran, pour certains cœurs, en raison du Turbo Boost, la valeur USED est supérieure à 100 %, car la fréquence du cœur est supérieure à la fréquence nominale.
Quelques mots sur la prise en compte de l'hyper-threading. Si les processus sont exécutés 100 % du temps sur les deux threads du cœur physique du serveur, alors que le cœur fonctionne à la fréquence nominale, alors :
- CORE UTIL pour le noyau sera de 100 %,
- PCPU UTIL pour les deux threads sera de 100 %,
- Le PCPU UTILISÉ 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, le PCPU UTILISÉ pour les cœurs est divisé en deux.
ESXTOP dispose également d'un écran avec les paramètres de consommation électrique du processeur du serveur. Ici, vous pouvez voir si le serveur utilise des technologies d'économie d'énergie : états C et états P. Appelé avec la touche "p":
Problèmes courants de performances du processeur
Enfin, je passerai en revue les causes typiques des problèmes de performances du processeur de la VM et donnerai de brefs conseils pour les résoudre :
La vitesse d'horloge de base n'est pas suffisante. S'il n'est pas possible de mettre à niveau votre VM vers des cœurs plus puissants, vous pouvez essayer de modifier les paramètres d'alimentation pour que Turbo Boost fonctionne plus efficacement.
Dimensionnement incorrect de la VM (trop/peu de cœurs). Si vous installez peu de cœurs, la charge CPU sera élevée sur la VM. S'il y en a beaucoup, faites un co-stop élevé.
Surabonnement important du CPU sur le serveur. Si la VM a un niveau Prêt élevé, réduisez le surabonnement du processeur.
Topologie NUMA incorrecte sur les grandes machines virtuelles. La topologie NUMA vue par la VM (vNUMA) doit correspondre à la topologie NUMA du serveur (pNUMA). Les diagnostics et les solutions possibles à ce problème sont écrits, par exemple, dans le livre . Si vous ne souhaitez pas aller plus loin et que vous n'avez pas de restrictions de licence sur le système d'exploitation installé sur la VM, créez de nombreux sockets virtuels sur la VM, un cœur à la fois. Vous ne perdrez pas grand chose :)
C'est tout pour moi à propos du processeur. Poser des questions. Dans la prochaine partie, je parlerai de la RAM.
Liens utiles
Source: habr.com