Introduction
ESXTOP est l’outil VMware de prédilection, il est simple et rapide pour troubleshooter un problème de performance sur un ESXi. Il permet de checker le CPU, la Mémoire (+Numa), le Storage et le Réseau.
Pour l’utiliser il faut se connecter sur l’ESXi en SSH et taper « esxtop ».
Les différents tableaux ci-dessous répertorient une liste non exhaustive des informations utiles à vérifier incluant une valeur maximale recommandée ainsi qu’une description brève. Les valeurs maximales sont données à titre indicatif d’après les divers tests et recherches que j’ai effectuée aussi bien sur le net qu’en labo.
vSphere 6.5
Depuis vSphere 6.5, plusieurs métriques ont été ajoutés comme la valeur %A/MPERF dans la vue Alimentation (p) affiche le pourcentage d’utilisation du Turbo Boost.
Sur un Processeur de 2,3 GHz nominal avec un Turbo Boost allant jusqu’à 3,6 GHz, un rapport aperf/mperf de 150% signifie que le processeur tourne autour de 3,5 GHz (2,3Ghz × 150% = 3,45Ghz).
Métriques et vMax
Pour changer les différentes vues on utilise les touches clavier :
- m: Mémoire
- c: Processeur
- n: Réseau
- i: Interruptions
- d: Gestion du Storage
- u: Storage
- v: VMDK
- p: Alimentation
- x: vSAN
Une fois sur une vue les touches on navigue en affichant des fields :
- f : Ajouter/Supprimer
- V : Afficher seulement les instance VM
- o : Changer l’ordre
- k : Tuer un World
- e : Développer
Processeur (Fields : D/F)
| Métrique | Nom | Explication | Valeur Max. | Solution |
| %USED | Used | Cycle de Core CPU utilisé par la VM | High | Améliorer la charge du Guest OS |
| %RUN | Run | % de temps que la VM tourne sur le système | ~0 ou
~vCPUS x 100% |
~0 Contention CPU ~vCPUSx100% Guest OS surchargé |
| %SYS | System Load | % de temps passé par le World | 10 | Diminuer les IO de la VM |
| %WAIT | Wait | % de temps que la VM patiente pour une activité VMkernel | High | Améliorer les performances du Storage |
| %VMWAIT | VM Wait | Pareil que %WAIT, sans l’IDLE Time | 100 | Améliorer les performances du Storage |
| %RDY | CPU Ready | % de temps que la VM est prête mais ne peux pas utiliser le pCPU | 10 | Décharger l’ESXi hôte ou réserver des ressources CPU |
| %CSTP | Co-stop | Usage excessif du vSMP | 3 | Diminuer le nombre de vCPU de la VM |
| %MLMTD | Max Limited | % de temps que le vCPU est prêt mais n’est pas autoriser pour ne pas violer la CPU Limit | 0 | Augmenter la valeur CPU Limit |
| %SWPWT | Swap Wait | VM en attente de lecture d’une page mémoire sur le disque | 5 | Diminuer l’overcomit mémoire |
Mémoire (Fields : B/D/J/K/Q)
| Métrique | Nom | Explication | Valeur Max. | Solution |
| MCTLSZ | Balloon Size | Force la VM à gonfler le ballon pour récupérer de la RAM | 0 | Diminuer la contention mémoire |
| SWCUR | Swapped | Force la VM à swapper pour récupérer la RAM | 0 | Diminuer la contention mémoire |
| SWR/s | Swap Read | Taux de lecture du fichier swap (vswp) | 0 | Diminuer la contention mémoire |
| SWW/s | Swap Write | Taux d’écriture du fichier swap (vswp) | 0 | Diminuer la contention mémoire |
| CACHEUSD | Cache Used | Force la VM à compresser pour récupérer la RAM | 0 | Diminuer la contention mémoire |
| ZIP/s | Zipping | Taux de compression de la RAM | 0 | Diminuer la contention mémoire |
| UNZIP/s | Decompression Rate | Taux de décompression de la RAM | 0 | Vérifier l’historique de la contention |
Numa (Fields : D/G)
| Métrique | Nom | Explication | Valeur Max. | Solution |
| NHN | Numa Node | Numéro du Node sur lequel la VM est placée | x | x |
| NRMEM | Numa Remote Memory | Quantité de RAM localisée sur le node distant | x | x |
| NLMEM | Numa Local Memory | Quantité de RAM localisée sur le node local | x | x |
| N%L | Numa Local | Taux de RAM localisée sur le node local | < 80 | Revoir l’optimisation NUMA (Idéal à 100%) |
Réseau (Fields : A/B/C/D/E/F/K/L)
| Métrique | Nom | Explication | Valeur Max. | Solution |
| %DRPTX | Dropped Packet Transmitted | Taux de paquets transmis « Dropped » | 0 | Décharger le réseau ou prioriser le trafic (NIOC) |
| %DRPRX | Dropped Packet Received | Taux de paquets reçu « Dropped » | 0 | Décharger le réseau ou prioriser le trafic (NIOC) |
Gestion du Storage (Fields : A/B/G/J)
| Métrique | Nom | Explication | Valeur Max. | Solution |
| GAVG | Guest Average | Latence Générale (DAVG+KAVG) | 25 | |
| DAVG | Device Average | Latence causé par le Datastore | 25 | Améliorer les performances du Storage |
| KAVG | Kernel Average | Latence causé par le Kernel | 3 | Solution de DAVG ou QUED |
| QUED | Queue Depth | Taille de la file d’attente | 0 | Augmenter la valeur « Queue Depth » |
| ABRTS/s | Aborts | Aborts provenant du Guest OS pour non réponse du Storage | 0 | Vérifier le Storage (Paths / IO) |
| RESETS/s | Resets | Taux de commandes réinitialisées | 0 | Vérifier le Storage |
| CON/s | Conflicts | Taux de conflits de réservation SCSI | 20 | Vérifier le Storage |
Bonjour ,
pour le métrique N%L de NUMA , la valeur max ne doit elle pas être plutot > 80 % et la plus proche de 100% plutôt qu’un max < 80 % ?
Et merci pour cette page web.
Bonjour,
Merci pour votre commentaire qui m’a permis de faire un « Edit ».
Alors je prends en valeur max celle qu’il ne faut pas dépasser, donc dans ce cas précis ne pas dépasser « moins de 80% » donc vMax < 80. Tout cela pour dire que oui, il faut la garder au dessus de 80% et le plus proche de 100%, pour avoir le plus possible de RAM sur le node local !
Merci Mathieu !