Analyse des performances VPS : optimiser le CPU Steal Time et les temps d'attente I/O

Je montre comment une analyse des performances VPS permet de mesurer le CPU Steal Time et les temps d'attente I/O et de mettre clairement en évidence les goulots d'étranglement dans l'hébergement de virtualisation. Avec des seuils, des outils et des étapes de réglage éprouvés dans la pratique, je réduis les temps de latence et maintiens les temps de réaction constants ; je me concentre sur CPU et E/S.

Points centraux

Avant de commencer, je résume les principales lignes directrices que j'estime nécessaires à une optimisation efficace des Performance utilise.

• Vol de CPU: Détecter les hôtes surchargés, mesurer %st, minimiser les voisins bruyants.
• Attente E/S: vérifier les chemins de stockage, réduire les latences grâce à la mise en cache et à NVMe.
• Mesure: combiner vmstat, iostat, top et PSI, lire les corrélations.
• Overcommit: surveiller l'attribution des vCPU et les temps de ready, fixer des limites.
• SLOs: définir des valeurs limites, suivre les valeurs aberrantes, planifier la migration à temps.

Ce que signifie réellement le temps volé au processeur

Steal Time décrit le temps de calcul perdu pendant lequel un vCPU doit attendre parce que l'hyperviseur donne la priorité à d'autres systèmes invités ; top l'affiche comme %st, ce n'est pas un temps de calcul. Idle-de temps. Les valeurs inférieures à 10 % ne sont généralement pas critiques, les plateaux persistants au-dessus indiquent une contention de l'hôte et une latence croissante, que je traite immédiatement. Les voisins bruyants déclenchent souvent ces effets, par exemple par des pics Cron ou des sauvegardes que j'égalise dans le temps. Pour les débutants, il vaut la peine de jeter un coup d'œil à Comprendre le temps de vol CPU, pour pouvoir classer les symptômes plus rapidement. Dans mes audits, je corrèle toujours %st avec la charge de travail et les temps de réponse, afin de pouvoir déterminer la cause et l'effet. clair de se séparer.

Lire correctement les temps d'attente E/S

%wa élevé dans vmstat indique que les threads attendent des réponses de la mémoire ou du réseau, ce qui CPU est laissé en jachère. Dans les configurations de stockage partagées, ces temps d'attente augmentent rapidement, surtout si de nombreuses VM écrivent au hasard sur les mêmes LUN. Les SSD NVMe fournissent des latences nettement plus faibles dans les tests IOPS (par ex. 4k random) et réduisent la gigue, ce qui soulage sensiblement les bases de données. Je vérifie en outre les paramètres QD (Queue Depth) et Scheduler, car des paramètres erronés ralentissent les petites opérations d'écriture. Pour les charges de travail des CMS et des boutiques en ligne, la mise en cache en écriture est payante tant que je respecte les limites de cohérence et les sauvegardes. bâche unique.

Mesure : vmstat, iostat, top et PSI

Je démarre avec vmstat 1 et observe r, us, sy, id, wa, st ; r plus grand que le nombre de vCPU et en même temps %st élevé signale une machine surchargée. Hôtes. iostat -x 1 affiche await, svctm et util par périphérique, ce qui me permet d'identifier les points chauds du stockage. Avec top ou htop, je suis la charge par processus et je vérifie si quelques threads bloquent tout. Dans les environnements de conteneurs, je lis également PSI sous /proc/pressure/cpu et /proc/pressure/io pour voir les modèles d'attente dans le temps. Je combine ces sources pour obtenir une image cohérente avant de procéder à des optimisations. mettre en œuvre.

Identifier les valeurs limites, les SLO et les valeurs aberrantes

Je définis des SLO, environ 99 % de requêtes inférieures à 300 ms, et je les associe à un maximum de 5 % Voler et une faible latence d'E/S. Ensuite, j'évalue les séries temporelles : de courts pics de %st sont tolérables, des phases plus longues dégradent le débit et l'expérience client. Je compte les percentiles plus haut que les moyennes, car certaines valeurs aberrantes dominent les chemins critiques. Pour les bases de données, je contrôle les buckets de latence (1, 5, 10, 50 ms) afin que les pics ne passent pas inaperçus. Si les SLO basculent, je prévois immédiatement des contre-mesures telles que la migration en direct ou les limites de ressources avant de perdre des utilisateurs ; cela permet de préserver les performances. prévisible.

Limiter les causes : CPU vs. stockage vs. réseau

Si top affiche des %st élevés en l'absence de temps d'inactivité, on peut supposer que l'hôte est surchargé, tandis que des %wa élevés avec un CPU modéré indiquent un stockage ; je sépare ainsi Domaines propre. Si r dans vmstat est en corrélation avec l'augmentation du temps d'exécution des tâches de calcul simples, je prouve que le vol en est la cause. Si les mesures du CPU restent calmes, mais que iostat-await grimpe, je me concentre sur les goulots d'étranglement IOPS ou les réglages de la file d'attente. Pour les chemins réseau, j'utilise des échantillons de latence et j'observe les retransmissions afin de ne pas confondre perte de paquets et attente d'E/S ; je donne d'autres conseils dans Comprendre l'attente d'E/S. Ces étapes de diagnostic m'évitent de tourner les mauvaises vis et d'avoir les mêmes problèmes plus tard. Pointes reviennent.

Optimisations contre le CPU Steal Time

Je réduis le surdimensionnement du vCPU, car trop de vCPU génèrent une pression d'ordonnancement et prolongent le steal ; moins de cœurs avec une fréquence plus élevée aident souvent immédiatement. La vigilance NUMA est payante : je lie les charges de travail au nœud approprié et minimise les accès inter-nœuds. Des instances isolées avec des ressources réservées empêchent les influences de noisy neighbor, si le fournisseur le propose. Côté code, je supprime les boucles d'attente et remplace le polling par des événements pour que le CPU ne se bloque pas artificiellement. Parallèlement, je surveille la moyenne de charge par rapport au nombre de vCPU et j'enregistre des alarmes qui s'intensifient à partir de 5-10 % Steal ; je maintiens ainsi les temps de réaction. étroit.

Réduire les latences d'E/S : mise en cache et stockage

Je déplace les lectures à chaud vers Redis ou Memcached pour éviter que les données ne soient transférées à chaque fois d'un serveur à l'autre. disque doivent venir. Pour les chemins d'écriture, j'optimise les intervalles de validation et la taille des lots, ce qui me permet de regrouper les petites écritures. Les volumes basés sur NVMe avec des performances IOPS élevées réduisent considérablement les temps d'attente, en particulier avec 4k random. Au niveau du système de fichiers, je vérifie les options de montage et les alignements afin d'éviter une amplification d'écriture inutile. Dans Kubernetes, je définis des requêtes/limites, l'affinité des nœuds et des classes de stockage dédiées afin que les pods ne se partagent pas des ressources E/S limitées. bloquer.

Gérer l'overcommitment de l'hyperviseur de manière pragmatique

L'overcommitment se produit lorsque les fournisseurs vendent plus de vCPU qu'il n'y a de cœurs physiques ; il en résulte des temps de préparation plus longs et une augmentation sensible des coûts. Voler. J'observe le CPU-Ready via l'hyperviseur et en tire les conséquences à plus de 5 %. Le redimensionnement, les limites et les tâches par lots décalées dans le temps réduisent les conflits dans le planificateur d'hôtes. Si le fournisseur d'accès le supporte, j'utilise la migration en direct sur des hôtes plus calmes ou je réserve des types d'instances avec un faible overcommit. Je résume le contexte et les mesures dans Surcommande CPU pour que je puisse prendre des décisions basées sur les faits et rapide rencontre.

Vérification de la pratique : benchmarks et corrélations

Je valide la constance de l'hôte à l'aide de petites boucles d'évaluation, comme une série d'opérations nécessitant un processeur, dont je compare les temps d'exécution. Voler hin. Pour les disques, j'utilise des profils fio (randread/randwrite, 4k, QD1-QD32) et j'enregistre les IOPS, la bande passante et les percentiles de latence. Je contrôle les délais réseau en parallèle afin de ne pas mélanger les effets. Je fais tourner ces mesures plusieurs fois par jour afin de reconnaître les modèles journaliers et d'exclure les fenêtres de maintenance. Je corrèle les résultats avec les métriques d'application, ce qui me permet de montrer comment les pics affectent directement le chiffre d'affaires, la durée des sessions ou les taux d'erreur. ont un impact.

Choix du fournisseur et données de performance

Pour les charges de travail productives, je veille à ce que les valeurs monocœurs soient fortes, les IOPS élevées et la dispersion à long terme faible ; j'obtiens ainsi des temps de réponse courts. Latence. Dans les tests, les fournisseurs avec un overcommitment limité fournissent des temps de réaction mesurablement plus constants. webhoster.de obtient souvent de très bons résultats dans les comparaisons, par exemple avec une performance single-core élevée et un steal time faible. Les machines virtuelles à budget peuvent suffire, mais pour les services critiques, je prévois des réserves et je calcule 12 à 40 € par mois pour des ressources fiables. Le tableau suivant montre des indicateurs typiques sur lesquels je me base pour prendre des décisions ; les valeurs sont indicatives et aident à la prise de décision. Classement.

Métriques	webhoster.de (1ère place)	Concurrence (moyenne)
Score unique	1.771+	1.200-1.500
IOPS (4k)	120.000+	50.000-100.000
Steal Time (Ø)	< 5 %	10-20 %
Attente E/S	Faible	Moyen-haut

Planifier les coûts et choisir les tarifs de manière intelligente

Je commence avec de petits plans qui offrent de bonnes performances à un seul cœur et je n'augmente que lorsque les goulets d'étranglement sont occupés ; ainsi, je ne paie que pour de véritables Besoins. Je planifie les pics de trafic avec des réserves de rafales et des mises à niveau à court terme, plutôt que de rester surdimensionné en permanence. Pour les services à forte intensité de données, je réserve des volumes NVMe plus rapides ou des classes de stockage dédiées, car le rapport qualité/prix est souvent meilleur que celui de la mise à niveau du processeur. Les VPS gérés sont intéressants si le fournisseur garantit une surveillance et un placement équilibré, ce qui réduit la probabilité de longues périodes de vol. Je vérifie les textes des accords de niveau de service et j'exige des métriques transparentes pour que mes SLO soient fiables. tiens.

Gouverneur de CPU, Turbo et C-States

Sur les machines virtuelles, la politique d'énergie du CPU influence directement la latence. Je vérifie si le gouverneur est réglé sur „performance“ et si les modes turbo sont utilisés de manière stable. Pour les services sensibles à la latence, je limite les C-States profonds afin que les cœurs ne doivent pas se réveiller à plusieurs reprises de leur état de sommeil. Dans des séries de mesures, je compare les temps de réponse avec différents réglages de gouverneurs et je retiens la meilleure combinaison. En outre, je contrôle la source d'horloge (tsc vs. kvmclock) et la synchronisation temporelle, car les horloges instables peuvent fausser les métriques et provoquer des temps morts. L'objectif : une horloge cohérente, pas de sauts de fréquence imprévisibles et des temps de réponse mesurablement plus courts sous charge.

Mémoire et swap comme pilotes d'E/S cachés

Outre le CPU et le disque, la pression de la mémoire freine également. Je surveille les taux de page par défaut, le cache libre et l'activité de swap ; si le swap in/out augmente, %wa explose souvent. Pour les applications nécessitant un cache important, je régule modérément la swappiness, prévois suffisamment de RAM et n'utilise zswap que de manière ciblée pour amortir les pics de burst. Je teste les Transparent Huge Pages en fonction de la charge de travail : les bases de données profitent en partie des Huge Pages statiques, les autres charges plutôt des défragmentations THP désactivées. Il est important de mettre en corrélation la pression de la mémoire avec le PSI (mémoire), afin que je puisse voir rapidement les risques d'OOM, les boucles de recouvrement et le thrash LRU. Moins de pression mémoire signifie généralement : une latence plus constante et moins d'arrêts d'E/S dus à l'externalisation.

Systèmes de fichiers, planificateurs et lecture anticipée

J'aligne le système de fichiers sur les charges de travail. Pour NVMe, je règle généralement le planificateur „none“, sur SATA/SSD, „mq-deadline“ ou „kyber“ font leurs preuves. J'adapte le read-ahead : les petits accès aléatoires (DBs, queues) avec un read-ahead faible, les tâches séquentielles (sauvegardes, ETL) avec une valeur plus élevée. Les options de montage comme noatime/nodiratime permettent d'économiser les écritures de métadonnées, un fstrim régulier maintient les performances du SSD stables. Pour ext4/xfs, je vérifie le mode journal et les intervalles de validation ; je réduis l'amplification en écriture par un alignement propre et un regroupement des petites écritures. Je mesure l'effet de chaque modification à l'aide des courbes d'attente et des percentiles de latence, et pas seulement à l'aide des chiffres IOPS bruts.

Point de vue du conteneur et du cgroupe : actions, quotas et throttling

Dans les conteneurs, les pics de latence sont souvent dus au throttling du CPU. Je préfère les requêtes/limites avec tampon pour que le noyau ne soit pas constamment ralenti. J'utilise des parts de CPU pour créer une équité relative, des quotas durs uniquement là où l'isolation est plus importante que la performance de pointe. Pour les E/S, je pondère les cgroupes (io.weight) et je limite les pires ouvreurs avec io.max, afin que les services sensibles puissent respirer. Je corrèle les signaux PSI par cgroup avec les temps de réponse P99 ; je vois ainsi si des pods individuels mettent l'hôte sous pression. Le résultat est une répartition de la charge planifiable, sans baisses brutales dues à des pénalités d'ordonnancement.

Reconnaître les modèles de charge de travail : Web, batch, base de données

Les API Web réagissent fortement au vol et à la gigue E/S cursive ; ici, je limite volontairement la cohérence (nombre de threads/travailleurs) et je maintiens les pools de connexion stables. Je déplace les tâches de traitement par lots en dehors des heures de pointe, j'abaisse leur priorité et je lisse le débit avec le traitement par lots. J'optimise les bases de données pour une faible latence de queue : stratégies de log-flush, buffer pool suffisant, et index secondaires découplés là où c'est utile. Pour les phases d'écriture intensive, je planifie de courtes „fenêtres de rafale“ à haute intensité et je maintiens une charge constante le reste du temps, au lieu de fonctionner en permanence sous une charge mixte sous-optimale. Des modèles clairs = moins de collisions avec les voisins sur le même hôte.

Routine de fonctionnement : alerting, runbooks et fenêtres de changement

J'associe des métriques techniques à des alertes SLO : %st sur 5-10 % pendant plus de N minutes, PSI-Stalls sur seuil, iostat-await sur des buckets de latence définis. J'associe les alertes à des runbooks : déclencher la migration, ajuster les limites, augmenter la mise en cache, adapter le read-ahead. J'effectue des modifications par petites étapes avec Mess-Gate ; je m'arrête lorsque les latences de queue se dégradent. Je coordonne les fenêtres de maintenance et les tâches de sauvegarde afin qu'elles ne pèsent pas simultanément sur le stockage et l'unité centrale. Cette discipline garantit que les améliorations ont un effet durable et qu'il n'y a pas de surprises dans les activités quotidiennes.

Mini-check-list pour un effet rapide

• Gouvernance : vérifier le gouverneur du CPU, stabiliser les C-States et la source d'horloge.
• Mesure : faire fonctionner vmstat/iostat/top/PSI en parallèle, établir des corrélations temporelles.
• CPU : vCPUs right-sizen, observer NUMA, supprimer les busy-waits, alarmes sur %st.
• I/O : utiliser NVMe, choisir le scheduler approprié, ajuster le read-ahead, planifier fstrim.
• Mémoire : Swappiness et THP spécifiques à la charge de travail, surveiller le cache de page et le PSI.
• Conteneur : Requêtes/limites avec tampon, définir io.weight, éviter le throttling.
• Exploitation : découpler les jobs batch, échelonner les sauvegardes, relier les alertes SLO aux runbooks.

En bref

Je me concentre sur les Analyse sur deux leviers : réduire le CPU Steal Time et raccourcir les temps d'attente I/O. Des mesures avec vmstat, iostat, top et PSI me fournissent une image de la situation, les corrélations avec les temps de réponse montrent l'effet. Ensuite, je prends des mesures ciblées : Right-Sizing, limites, attention NUMA, mise en cache et mémoire NVMe plus rapide. En cas de goulots d'étranglement persistants, je planifie la migration ou le changement de tarif avant que les clients ne ressentent la latence. Celui qui met en œuvre ces étapes de manière conséquente obtient des temps de réponse constants, protège les SLO et crée une fiable l'expérience des utilisateurs.