Passer au contenu 
Dans l'hébergement virtuel, le CPU Steal Time décrit le temps CPU perdu qu'une VM doit céder à l'hyperviseur et explique de nombreux pics de latence par Noisy Effets de voisinage. Je montre concrètement comment ces signaux apparaissent, comment je les mesure et quelles mesures permettent de garantir une performance durable sans que vos voisins vCPU freiner.
Points centraux
- Voler du temps: Attente du vCPU, car l'hôte dessert d'autres systèmes invités.
- Noisy Neighbor: les colocataires consomment trop de CPU, de RAM ou d'E/S
- Mesure: Interpréter correctement %st dans top, vmstat, iostat
- Seuils: En dessous de 10 %, généralement acceptable, au-dessus, négocier
- Solutions: Redimensionnement, limites, migration, bare metal
Ce que signifie réellement le temps volé au processeur
Je définis le « steal time » comme la part de temps pendant laquelle un vCPU est disponible, mais ne reçoit pas de temps de calcul sur le CPU physique, car l'hyperviseur privilégie d'autres systèmes invités et, par conséquent, CPU-Slots occupés. Cette valeur apparaît dans des outils tels que top sous la forme %st et ne décrit pas un temps d'inactivité, mais des fenêtres d'exécution effectivement perdues pour vos processus, qui se traduisent par des retards perceptibles et donc Latence . Des valeurs allant jusqu'à environ 10 % sont souvent considérées comme acceptables, les pics courts étant tolérables, mais les plateaux plus longs marquent de véritables goulots d'étranglement et nécessitent une intervention afin que les charges de travail ne s'enlisent pas et ne produisent pas de délais d'attente qui frustrent les utilisateurs et coûtent des conversions, car Requêtes rester bloqué. Je fais une distinction stricte entre le temps d'inactivité et le temps volé, car en cas de temps d'inactivité, ce n'est pas l'hôte qui limite, mais votre invité, tandis qu'en cas d'absence de temps d'inactivité et de temps volé élevé, la charge de l'hôte ralentit et ainsi Débit Pour moi, Steal Time fournit ainsi un signal d'alerte précoce : lorsque les temps de réponse augmentent et que le vCPU attend, il y a souvent une contention de l'hôte, que je peux mesurer et éliminer de manière ciblée avant que les goulots d'étranglement ne s'aggravent et que les applications ne deviennent peu fiables, car planificateur Il manque des emplacements.
Noisy Neighbor dans l'hébergement virtuel
Je qualifie de « voisin bruyant » tout locataire qui utilise de manière excessive le CPU, la RAM ou les E/S, retardant ainsi l'exécution de vos processus sur le même hôte, ce qui se traduit par une augmentation sensible Voler Time affiche. Cet effet se produit dans les environnements multi-locataires lorsque les sauvegardes, les tâches cron ou les pics de trafic nécessitent plus de temps de calcul que l'hôte ne peut en répartir équitablement, ce qui fait grimper votre latence et Performance fluctue. Dans les conteneurs, les fermes VM et les clusters Kubernetes, les chemins réseau et stockage communs amplifient les effets, car les goulots d'étranglement se répercutent en cascade et bloquent plusieurs niveaux simultanément, ce qui rend les temps de réponse imprévisibles et Jitter renforcé. Je constate souvent que les pics à court terme ne sont pas causés par un seul perturbateur, mais par de nombreux locataires simultanément, ce qui fait basculer la charge globale et augmente la file d'attente du processeur jusqu'à ce que l'hyperviseur vCPU plus tard. Si vous souhaitez déterminer plus rapidement la cause, vérifiez également les éventuelles Survente dans l'hébergement, car les hôtes surchargés augmentent la probabilité de conflits et font sensiblement augmenter le temps volé, en l'absence de limites et contention augmente.
Méthodes de mesure et valeurs seuils
Je lance le diagnostic sur le shell avec top ou htop et j'observe attentivement la valeur %st, qui m'indique le temps d'attente pour les ressources hôtes, ainsi que %id, afin de détecter les temps morts et Corrélation Pour obtenir des résultats plus précis, j'utilise vmstat toutes les secondes, car la colonne st permet de visualiser les pics, tandis que iostat et sar fournissent en complément les proportions de temps d'E/S et de CPU, que je compare aux latences des applications afin de Causes Si %st dépasse à plusieurs reprises la barre des dix pour cent pendant plusieurs minutes, je déclenche des alarmes et je corrèle les plages horaires avec les journaux du serveur web, les traces APM et les heures de la base de données, afin de pouvoir distinguer les goulots d'étranglement de l'hôte des problèmes d'application et ne pas me lancer dans une optimisation aveugle qui Erreur masqué. Je prête également attention aux temps de disponibilité du processeur dans les outils d'hyperviseur, car ceux-ci indiquent la file d'attente sur l'hôte et expliquent pourquoi certains cœurs ne fournissent parfois que très peu de slots lorsque de nombreux vCPU fonctionnent simultanément et planificateurLa pression augmente. Si vous soupçonnez également une limitation, vérifiez les modèles pour les limites du processeur et lisez les valeurs mesurées ensemble, une approche que j'ai décrite dans ce guide sur Détecter la limitation du CPU approfondis afin d'éviter toute interprétation erronée et de garantir la cohérence du diagnostic.
Comment le « steal time » se produit techniquement et comment je le mesure
Je ne me fie pas uniquement aux pourcentages, mais je consulte directement les sources du système. Sous Linux, la commande /proc/stat La base : la colonne voler compte les jiffies pendant lesquels le noyau aurait aimé fonctionner, mais n'y a pas été autorisé par l'hyperviseur. À partir de là, je calcule les proportions par intervalle et j'obtiens des courbes robustes que je superpose aux métriques de l'application. mpstat -P ALL 1 indique, pour chaque cœur, dans quelle mesure les différents processeurs logiques sont affectés, ce qui est important lorsque seuls quelques cœurs „ chauds “ sont planifiés. Avec pidstat -p ALL -u 1 Je vois également quels processus consomment combien usr/sys consommer, tandis que %st élevée, ce qui évite les causes apparentes.
Je mesure en complément Prêt pour le CPU dans l'hyperviseur (par exemple en millisecondes par seconde) et établissez une corrélation : temps de disponibilité élevé sans inactivité et augmentation %st indiquent clairement une pression de l'hôte. Important : Attente E/S n'est pas une bonne affaire – si %wa est élevé, il manque plutôt des emplacements de stockage/réseau ; j'optimise alors les profondeurs de file d'attente, les caches et les chemins d'accès au lieu de rechercher un processeur. Pour les hôtes de conteneurs, je lis /proc/pressure/cpu (PSI) et observez les événements „ some “/„ full “ qui présentent des modèles d'attente fins lorsque de nombreux threads se disputent les cœurs.
Dans la pratique, je recourt à un simple test de boucle lorsque je soupçonne des affichages erronés : un benchmark court et gourmand en ressources CPU (par exemple, un cycle de compression) devrait fournir un temps quasi constant sur un hôte stable. Si la durée d'exécution varie fortement et %st saute, c'est un indice de contention. Je vérifie ainsi si les métriques et les performances perceptibles correspondent.
Interpréter correctement les différences entre hyperviseurs et systèmes d'exploitation
Je distingue les métriques selon la plateforme : sous KVM et Xen, %st Du point de vue de l'invité, il s'agit assez directement du temps CPU retenu. Dans les environnements VMware, l'indicateur Prêt pour le CPU joue un rôle plus important ; ici, je traduis „ ms ready pro s “ en pourcentage (par exemple, 200 ms/s correspondent à 20 % Ready) et j'évalue en combinaison avec %id dans l'invité. Les invités Windows ne fournissent pas de „ steal “ direct, je lis les compteurs Hyper-V/VMware et j'interprète les valeurs conjointement avec l'utilisation du processeur et Longueur de la file d'attente d'exécution. Je documente ces différences afin que les équipes ne comparent pas des pommes et des poires et ne fixent pas de valeurs limites erronées.
Je tiens également compte des modes d'économie d'énergie et SMT/Hyper-Threading: les cœurs logiques se partagent les unités d'exécution – une charge élevée sur un thread peut ralentir le jumeau sans que l'hôte soit surchargé. Je vérifie donc via lscpu la topologie et attribue les threads aux cœurs afin de détecter la „ surcharge fantôme “ due au SMT.
Délimiter les conteneurs, les cgroups et la limitation du temps volé
Dans les configurations de conteneurs, je distingue trois éléments : Voler (hôte retire le CPU), Throttling (les limites du SFC freinent) et pression liée à la planification à l'intérieur du pod. Dans cgroup v2, cpu.stat les champs nr_throttled et throttled_usec, que je compare aux courbes de vol. Si throttled_usec, alors que %st est faible, c'est votre propre configuration qui limite, et non l'hôte. C'est pourquoi je planifie dans Kubernetes Requêtes et Limites réaliste, attribue aux pods critiques la classe QoS „ Guaranteed “ et utilise cpuset, lorsque j'ai besoin d'une isolation stricte. Cela m'évite de blâmer un pod alors que la limite est plus stricte que la charge de travail.
Je définis consciemment mes priorités : les tâches de compilation, les sauvegardes et les processus par lots sont classés en priorité sympaet des limites afin que les charges de travail interactives ou API soient prioritaires aux heures de pointe. Cette hiérarchisation simple réduit sensiblement les latences et diminue Jitter, sans que je doive migrer immédiatement.
Topologie CPU : NUMA, pinning et governor
Je prends en compte la structure physique : sur les systèmes NUMA, l'accès à la mémoire à distance détériore la latence lorsque les vCPU sont répartis sur plusieurs nœuds. C'est pourquoi j'épingle spécifiquement les vCPU pour les services sensibles (Épinglage du processeur) et conservez la mémoire en local afin que Débit reste stable. Dans Gast, je règle le régulateur CPU sur „ performance “ ou je fixe les fréquences dans les fenêtres de charge lorsque les fluctuations de boost entraînent des variations. Pour les exigences strictes en temps réel, des options telles que isolcpus et nohz_full Noyaux de bruit système ; ce n'est pas une panacée, mais cela réduit les facteurs perturbateurs qui seraient autrement interprétés à tort comme des „ vols “.
Différences selon le type d'hébergement
Dans la pratique, je fais une distinction claire entre les VPS partagés, les VPS gérés et les serveurs bare metal, car ces variantes présentent des profils de risque très différents en termes d'effets « noisy neighbor » et donc en termes de Voler Time. Le VPS partagé partage les cœurs sans garanties strictes, ce qui explique pourquoi des temps d'attente notables apparaissent régulièrement sur les hôtes très sollicités, entraînant des temps de réponse variables et affectant vos SLAs mettre sous pression. Les VPS gérés avec des limites claires et un équilibrage actif des hôtes affichent des valeurs nettement plus stables, à condition que le fournisseur limite le surengagement, effectue une surveillance et utilise la migration à chaud, ce qui se traduit dans les journaux par une plus grande régularité. Latence visible. Bare Metal élimine complètement cet effet, car il n'y a pas de locataires tiers et le CPU appartient exclusivement à votre application, ce qui garantit une prévisibilité constante et Peaks facilite la gestion. Le tableau suivant résume les différences de manière concise et aide à lier les décisions aux objectifs de charge de travail plutôt qu'au prix seul, qui entraîne sinon des coûts supplémentaires dus aux pannes et Revenu diminue.
| Type d'hébergement | Risque de voisinage bruyant | Temps d'utilisation du processeur prévu | Mesures typiques |
|---|---|---|---|
| VPS partagé | Haute | 5–15 % | Vérifier les limites, demander la migration |
| VPS géré | Faible | 1–5 % | Équilibrage des hôtes, dimensionnement adéquat des vCPU |
| Métal nu | Aucun | ~0 % | Noyaux exclusifs, réservations |
Causes : surengagement, pics et code propre
Je vois trois facteurs principaux : un hôte surchargé, des locataires qui se stabilisent simultanément et un code inefficace qui sollicite inutilement le processeur et temps d'attente provoqué. Le surengagement survient lorsque les fournisseurs attribuent plus de vCPU que les cœurs physiques ne peuvent en traiter de manière fiable, ce qui entraîne des files d'attente Ready pendant les phases de charge et peut augmenter la métrique %st, même si votre App fonctionne correctement. Parallèlement, un code de mauvaise qualité peut générer des boucles de sondage qui consomment beaucoup de CPU, ce qui fait que même avec un hôte libre, votre VM semble très sollicitée, de sorte que les goulots d'étranglement réels se trouvent ailleurs et Optimisation nécessaire. À cela s'ajoutent des tâches hôtes telles que les sauvegardes, la compression ou la migration en direct, qui nécessitent des créneaux à court terme et provoquent des pics que je ne prends vraiment en compte qu'à partir d'une certaine durée, car les micro-pics sont normaux et Exploitation peuvent avoir une incidence négative. En séparant clairement les causes, on gagne du temps : il faut d'abord mesurer, puis tester des hypothèses, puis agir, sinon on ne fait que repousser les problèmes au lieu de les résoudre et Stabilité à atteindre.
Comment je distingue Steal Time des problèmes liés aux applications
Je corrèle les métriques système avec les données applicatives telles que la durée des traces, les temps de requête et les journaux du serveur web afin de séparer la contention hôte du code propre et de cibler Corrections . Si %st augmente de manière synchrone avec les temps de disponibilité et sans temps d'inactivité, je soupçonne une pression sur l'hôte, tandis qu'une utilisation élevée du processeur dans la machine virtuelle associée à un temps de vol faible indique plutôt une optimisation de l'application, que je valide à l'aide de profileurs et Points chauds réduire. Pour les charges de travail avec des pics, je planifie la capacité de manière réactive et statique : à court terme, j'augmente le nombre de cœurs, à long terme, je fixe des limites, des réservations ou des cœurs dédiés afin de garantir la prévisibilité et QoS est respectée. Lorsque les profils de charge semblent irréguliers, je privilégie les formes de suppléments à court terme qui garantissent les pics sans entraîner de coûts élevés permanents, car cela permet de maintenir la courbe des coûts à un niveau stable et Performances en rafale évite les goulots d'étranglement lors du lancement des campagnes et Trafic augmente. Je documente chaque modification avec un horodatage, ce qui me permet d'identifier les effets et d'annuler rapidement les mauvaises décisions si les indicateurs basculent et Impact devient visible.
Mesures concrètes à prendre au quotidien
Je commence par le dimensionnement : j'adapte le nombre et la cadence des vCPU à la charge de travail afin que le planificateur trouve suffisamment de slots et que la Queue reste court. Ensuite, je fixe des limites de ressources et des quotas afin que les processus individuels ne monopolisent pas les cœurs, ce qui est particulièrement utile dans les conteneurs et atténue les conflits d'hôtes, car Frontières Si le Steal Time reste élevé de manière permanente, je demande au fournisseur une migration en direct vers un hôte moins sollicité ou j'effectue moi-même un changement si les politiques le permettent et Temps d'arrêt minimiser. Pour les systèmes sensibles, je choisis des cœurs dédiés ou du bare metal, car cela élimine complètement les effets de voisinage et rend la latence prévisible, ce qui protège les SLO et Pointes calculable. En parallèle, j'optimise le code, les caches et les index de la base de données afin de réduire la charge CPU par requête, ce qui atténue l'impact du steal time et améliore les Résilience augmente.
Rapport coût-bénéfice et critères de migration
Je base mes décisions sur un calcul simple : combien de chiffre d'affaires ou de productivité interne perd-on à chaque seconde supplémentaire de latence, et combien coûte une mise à niveau des ressources par mois en Euro. Si les économies réalisées grâce à des temps de réponse plus rapides couvrent le surcoût, je passe à la vitesse supérieure, sinon je préfère l'optimisation jusqu'à ce que les valeurs mesurées clarifient la situation et Budget convient. Je définis comme critères de migration des valeurs %st supérieures à 10 %, des pics de latence récurrents pendant les heures de pointe et l'absence d'amélioration après l'optimisation du code, car dans ce cas, il ne reste plus qu'à changer d'hôte ou à passer à Bare Metal pour que SLIs être respectées. Pour les configurations avec des fenêtres critiques, je définis un concept par étapes : à court terme, l'autoscaling, à moyen terme, des cœurs dédiés, à long terme, des hôtes isolés, afin que les risques et les coûts restent équilibrés et Planification fiable. Je calcule également les coûts d'opportunité : des prospects manqués, une conversion moindre et des frais d'assistance supplémentaires sont à prévoir lorsque les pages se chargent lentement et que les utilisateurs quittent le site, ce qui revient indirectement plus cher que d'acheter plus de cœurs ou de mémoire vive. RAM.
Guide pratique du monitoring en 7 jours
Le premier jour, je définis des indicateurs de base : CPU‑%st, %id, charge, temps de préparation, attente E/S et latence des applications, afin de voir immédiatement les corrélations et Ligne de base . Les deuxième, troisième et quatrième jours, je vérifie les profils de charge, j'identifie les pics en fonction de l'heure et des types de tâches, je désactive les tâches cron inutiles et j'ajuste le nombre de travailleurs jusqu'à ce que les courbes se stabilisent et Fils de discussion travailler de manière uniforme. Jusqu'au cinquième jour, je teste les limites et les priorités, je répartis les charges de travail entre les cœurs et je vérifie que les tâches en arrière-plan ne s'exécutent pas pendant les heures de pointe, ce qui réduit la file d'attente de l'hôte et Jitter diminue. Le sixième jour, je simule une charge avec des tests synthétiques, j'observe %st et les temps de réponse, puis je décide d'augmenter les vCPU ou de lancer la migration si les plateaux persistent et Valeurs limites démolir. Le septième jour, je documente les résultats, enregistre les tableaux de bord et les alertes et comble les lacunes afin que les pics futurs soient détectés à temps et Incidents devenir plus rares.
Alertes et conception SLO pour une latence constante
Je formule les alertes de manière à ce qu'elles déclenchent une action et ne soient pas ignorées : avertissement à partir de 5 % %st plus de 10 minutes, critique à partir de 10 % pendant 5 minutes, corrélées respectivement avec les latences p95/p99. Si les latences n'augmentent pas, l'alarme est „ en observation “, je collecte des données au lieu de passer à l'étape suivante. J'ajoute une deuxième ligne : Prêt pour le CPU > 5 % pendant 5 minutes au niveau de l'hyperviseur. Ces deux conditions combinées constituent pour moi le signe le plus évident d'une pression sur l'hôte. Pour les SLO, je définis des objectifs stricts (par exemple, 99 % des requêtes en moins de 300 ms) et je mesure la part du budget d'erreurs consommée par les pics de vol. Cela me permet de décider de manière structurée quand je dois évoluer ou migrer, plutôt que d'agir de manière instinctive.
Sur le plan opérationnel, je veille à ce que les textes d'alerte soient concis : „ %st > 10 % et p99 > objectif – vérifier : charge voisine, Ready, limites, migration à chaud “. Cela permet de gagner quelques minutes lors d'un incident, car le runbook est fourni immédiatement. De plus, je définis „Heures calmes“ Règles pour les fenêtres de maintenance connues afin que les pics prévus ne génèrent pas d'alarmes critiques erronées.
Planification des capacités : règles empiriques relatives à la marge disponible et à la surengagement
Je planifie consciemment marge: 20 à 30 % de CPU libre aux heures de pointe, c'est mon minimum pour éviter que des coïncidences aléatoires liées au trafic et aux tâches hôtes ne déclenchent des réactions en chaîne. Pour les rapports vCPU:pCPU, je fais des calculs prudents : plus la sensibilité à la latence est élevée, plus le surengagement est faible (par exemple 2:1 au lieu de 4:1). Pour les charges de travail avec des pics périodiques, je combine le scaling horizontal et vertical : à court terme, plus de répliques, à moyen terme, des cadences/cœurs plus élevés, à long terme, des réservations claires ou cœurs dédiés. Cela me permet de planifier mes coûts et de rester opérationnel en cas de pics d'activité.
Lorsque les fournisseurs utilisent des modèles basés sur les pics d'activité, je fais la distinction entre les „ crédits manquants “ et le vol pur et simple : si le temps CPU augmente sans augmentation des %st limite le budget de crédit ; augmente %st, la capacité de l'hôte est insuffisante. Cette distinction permet d'éviter les mauvaises décisions telles qu'une migration précipitée, alors qu'un seul type d'instance ne correspond pas au profil.
Liste de contrôle pratique pour un effet rapide
- Calibrer les métriques: %st, %id, Ready, p95/p99, PSI, cgroup cpu.stat
- Égaliser la charge: déplacer la fenêtre Cron, limiter les workers, définir nice/ionice
- Ajuster les limites: Requêtes/limites Kubernetes, quotas, cpuset pour les pods critiques
- Vérifier la topologie: Tester les performances SMT, NUMA, Pinning, Governor
- Ajuster la taille: augmenter progressivement le nombre de vCPU et la fréquence d'horloge, mesurer l'effet
- Intégrer un fournisseur: Lancer la migration en direct, demander l'équilibrage de l'hôte
- Isoler si nécessaire: cœurs dédiés ou bare metal pour les SLO exigeants
Résumé pour des décisions rapides
Je considère le temps d'utilisation du processeur comme un indicateur clair de contention de l'hôte qui, s'il dépasse 10 % pendant une période prolongée, nécessite une action active avant que les utilisateurs ne quittent le site et SEO souffre. Contre les voisins bruyants, le redimensionnement, les limites, la migration d'hôte et, si nécessaire, les cœurs dédiés ou le bare metal aident à maintenir la latence prévisible et SLAs maintenir. La mesure est réalisée à l'aide de %st, des temps de préparation et des données APM, toujours interprétés conjointement afin de ne pas confondre cause et effet et Décisions . Si vous souhaitez garder un œil sur les coûts, liez les étapes de mise à niveau aux gains de chiffre d'affaires ou de productivité en euros, au lieu de vous concentrer uniquement sur les prix des serveurs, car la disponibilité a un impact direct sur Rendement . Si je mesure correctement le vol de temps, que j'en identifie les causes et que j'agis de manière cohérente, l'hébergement virtuel reste rapide, fiable et exempt de voisins bruyants qui volent des performances et Utilisateur frustrer.
