Diagnostiquer le temps de vol de CPU (steal time) sur des hôtes Linux virtualisés avec mpstat et vmstat

Objectif

Distinguer l'épuisement réel du CPU du temps que le vCPU d'une machine virtuelle a passé à attendre que son hôte l'ordonnance, avant de chercher une correction côté application qui ne peut pas exister.

Prérequis

Un invité Linux exécuté sous un hyperviseur (KVM, Xen, VMware ou une VM cloud) qui expose à l'invité une horloge de steal time (KVM et Xen le font ; tous les hyperviseurs et noyaux invités ne la remontent pas). Il faut le paquet sysstat pour mpstat et procps pour vmstat, généralement préinstallés ou installables de façon non interactive (DEBIAN_FRONTEND=noninteractive apt-get install -y sysstat / dnf install -y sysstat).

Étapes

1. Obtenez une ventilation par CPU sur une courte fenêtre : mpstat -P ALL 1 5. Le manuel de sysstat définit %steal comme le pourcentage de temps passé en attente involontaire par le CPU virtuel pendant que l'hyperviseur servait un autre processeur virtuel. C'est du temps pendant lequel le noyau de l'invité voulait s'exécuter sans le pouvoir, et non du temps passé à effectuer un travail quelconque.
2. Recoupez avec un second outil : vmstat 1 5. La colonne st est documentée comme le temps volé à une machine virtuelle ; elle devrait suivre approximativement la ligne all du %steal de mpstat. Ignorez la première ligne de vmstat, qui est une moyenne depuis le démarrage et non l'intervalle courant.
3. Lisez le motif, pas seulement la valeur : un steal réparti uniformément sur tous les CPU pendant l'intervalle suggère une contention d'ordonnancement à l'échelle de l'hôte ; un steal qui n'apparaît que lorsque votre propre charge est limitée par le CPU suggère que l'hôte est sursouscrit pour ce type de charge. Le steal ne s'accumule que lorsqu'un vCPU a du travail à exécuter : un invité surtout inactif affiche peu de steal, même sur un hôte chargé.
4. Traitez-le comme une question de placement ou de capacité, et non comme un bogue de code : rien sur l'invité ne permet de voir ce que faisaient les machines virtuelles voisines à ce moment-là. Un steal soutenu et significatif (nettement au-dessus des brèves fluctuations à un chiffre) mérite d'être signalé à la personne qui contrôle l'hyperviseur. Sur les types d'instances cloud à capacité « burstable », l'épuisement des crédits CPU peut aussi apparaître sous forme de steal.
5. Sur du matériel physique (bare metal), %steal et st sont structurellement nuls, puisqu'il n'existe aucun hyperviseur pour retenir du CPU ; une valeur non nulle laisse penser que le système est en réalité un invité, contrairement à ce que l'on supposait.
6. Si vous contrôlez aussi l'hyperviseur, corrélez avec ses propres métriques par VM de CPU ready ou d'attente de l'ordonnanceur, qui confirment depuis l'autre côté ce que l'invité ne peut que déduire.

Résultat attendu

Une séparation nette entre « l'application a utilisé tout le CPU qui lui était alloué » (steal faible, us/sy élevés) et « l'application s'est vu refuser du CPU qu'elle demandait » (steal significatif et soutenu). Cela fait passer l'étape suivante du profilage du code à une discussion de capacité.

Limites et base de vérification

Les deux commandes sont en lecture seule ; il n'y a rien à sauvegarder ni à annuler. Aucun des deux outils ne peut désigner le locataire responsable de la contention. Certaines configurations d'hyperviseur (épinglage des CPU, cœurs dédiés) ne produisent jamais de steal, même sous charge, et certains hyperviseurs ne remontent pas du tout le steal à l'invité : un steal nul ne prouve donc pas à lui seul l'absence de contention côté hôte. Les définitions citées sont celles des outils eux-mêmes, et non un seuil de gravité universel.