Passer au contenu 
Je montre étape par étape comment l'analyse I/O Wait avec iostat et vmstat met en évidence les goulots d'étranglement et quelles sont les métriques Linux Server qui comptent pour des temps de réaction rapides. Je fixe des seuils clairs, interprète des modèles typiques et propose des mesures concrètes pour l'optimisation de E/S et CPU un.
Points centraux
- iostat et vmstat fournissent une vue complémentaire de la charge de l'unité centrale et du stockage.
- wa sur le 15-20% et %util via le 80% montrent un goulot d'étranglement d'E/S.
- await et avgqu-sz expliquent la latence et les files d'attente.
- mpstat détecte les charges inégalement réparties sur les cœurs du processeur.
- Tuning va de MySQL aux paramètres du noyau et au stockage.
Que signifie I/O Wait sur les serveurs Linux ?
Sous I/O-Wait, le CPU attend sans rien faire parce qu'il est en attente de périphériques de stockage ou de réseau plus lents, ce qui est wa-dans des outils comme top ou vmstat. J'évalue ce pourcentage comme le temps pendant lequel les threads se bloquent et les requêtes se terminent plus tard, ce que les utilisateurs ressentent directement comme une inertie. Les valeurs supérieures à 10-20% indiquent souvent une saturation de la mémoire. Stockage-lorsque les disques durs, les baies RAID ou les montages NFS sont saturés. Dans les configurations d'hébergement avec des bases de données, les requêtes non indexées et les pics d'écriture s'ajoutent aux temps d'attente inutiles sur le serveur. disque. Les personnes qui souhaitent rafraîchir les concepts trouveront des bases sous Comprendre l'attente d'E/S, J'ai besoin d'un peu de temps avant de me rendre au cabinet.
Démarrage rapide : lire correctement vmstat
Avec vmstat, je vérifie en quelques secondes les principaux Linux-et j'identifie les premiers modèles sans grand effort. L'appel vmstat 1 10 fournit dix instantanés, dans lesquels je prête une attention particulière aux colonnes wa (attente E/S), bi/bo (E/S en bloc) et si/so (échange). Des valeurs bo élevées associées à une augmentation de wa indiquent pour moi de nombreux accès en écriture bloquants, ce qui indique souvent des limites de tampon ou des supports lents. Si si/so reste à zéro, mais que wa augmente nettement, cela signifie qu'il s'agit d'une erreur pure. Stockage-limite de la mémoire. Dans les hôtes multi-core, je combine vmstat avec mpstat -P ALL 1, car la wait I/O ne concerne souvent que quelques cœurs et semble donc plus inoffensive en moyenne générale qu'elle ne l'est en réalité.
Image fine du CPU : us/sy/st, file d'attente d'exécution et changement de contexte
Avec vmstat et mpstat, je lis plus de waHaute : Haute us-Les parts de marché de l'industrie de l'informatique montrent un travail d'application à forte charge de calcul, sy indique un travail du noyau/pilote, par exemple lors d'une utilisation intensive E/S. Dans les environnements virtualisés, je prends en considération st (steal) (vol) : Des valeurs st élevées signifient que la VM perd du temps de CPU, ce qui gonfle artificiellement les latences pour un modèle d'E/S identique. Je compare également la file d'attente d'exécution (r dans vmstat) avec le nombre de CPU : un r durablement supérieur au nombre de CPU indique une congestion au niveau du CPU, et non du Stockage. Beaucoup de changements de contexte (cs) en combinaison avec de petites écritures synchrones sont un indicateur des schémas d'E/S Chatty. Ainsi, j'évite de mal interpréter une pénurie de CPU comme un problème d'E/S.
Comprendre iostat en profondeur : les métriques importantes
iostat -x 1 me fournit des données étendues disque-métriques qui décrivent proprement la latence, l'utilisation et les files d'attente. Je commence à mesurer les pics de charge et je corrèle %util, await, svctm et avgqu-sz pour distinguer la cause de l'effet. Si %util monte à 90-100%, alors que await et avgqu-sz montent aussi, je vois une saturation de l'espace. Plaque ou un volume limité. Si await affiche des valeurs élevées avec un %util modéré, je vérifie les interférences dues à la mise en cache, aux limites du contrôleur ou à de grandes requêtes isolées. r/s et w/s apportent de la fréquence à l'image, tandis que MB_read et MB_wrtn expliquent le volume, ce qui me fournit des valeurs de comparaison importantes pour les configurations SSD et NVMe dédiées.
NVMe, SATA et RAID : ce que signifient %util, await et Queue-Depth
Je fais une stricte distinction entre les types de médias : HDD montrent des taux plus élevés await-Les valeurs de l'indice d'alcoolémie sont déjà faibles avec une queue de billard modérée, car les mouvements de la tête dominent. SSD/NVMe évoluent bien avec le parallélisme, c'est pourquoi une plus grande avgqu-sz peut être normal, tant que await reste dans les limites. Sur NVMe avec plusieurs files d'attente de soumission/complétion, je lis %util avec plus de retenue : des périphériques individuels peuvent déjà être à la limite à 60-70% si l'application ne génère pas assez de parallélisme ou si la profondeur de la file d'attente (nr_requêtes, queue_depth) est trop petit. Dans le site RAID je vérifie si des E/S aléatoires dispersées rencontrent des bandes de taille trop petite ; dans ce cas, les E/S aléatoires augmentent. await et %util de manière inégale sur les disques membres. C'est pourquoi je regarde l'iostat par périphérique membre, et pas seulement sur le volume assemblé, afin de mettre en évidence les points chauds. Pour les couches structurées par des logs (par ex. Copy-on-Write), je m'attends à des latences un peu plus élevées pour les écritures, mais je compense en agrandissant les fenêtres de writeback ou en utilisant le batching côté app.
Flux de travail de diagnostic pour des temps d'attente élevés
Je démarre chaque analyse en parallèle avec vmstat 1 et iostat -x 1, afin de voir les états du CPU et du périphérique de manière synchrone et de pouvoir les attribuer dans le temps. Ensuite, je vérifie avec mpstat -P ALL 1 si certains cœurs sont anormalement élevés. wa ce qui évite des valeurs moyennes mal interprétées. S'il y a des indices d'un responsable, j'utilise pidstat -d ou iotop pour voir, processus par processus, quel PID utilise le plus d'E/S. Dans les environnements d'hébergement avec des bases de données, je distingue d'abord les pics de lecture des pics d'écriture, car les stratégies de retour en écriture et les modèles fsync génèrent des symptômes très différents et permettent ainsi de cibler les pics de lecture. Mesures permettent d'y parvenir. Pour les questions de stockage plus approfondies, une vue d'ensemble comme celle de Bottleneck d'E/S dans l'hébergement, J'ai besoin d'un peu de temps avant d'intervenir sur le noyau ou le système de fichiers.
Délimiter proprement la virtualisation et les conteneurs
Dans les VM, je considère wa avec st (Steal) et mesure en plus sur l'hyperviseur, car c'est le seul endroit où les vrais appareils et les Queues de billard sont visibles. Les agrégations de stockage (thin provisioning, dedupe, snapshots) déplacent les pics de latence vers le bas de la pile - dans la VM, cela fait alors effet await de façon spectaculaire, tandis que %util reste discret. Dans les conteneurs, je limite ou je découple E/S avec des règles de Cgroup (par exemple, les limites IOPS/Throughput) pour Voisins bruyants de l'apprivoiser. Je documente les limites par service afin que les valeurs mesurées soient reproductibles et que les alarmes conservent leur contexte. Important : un niveau élevé wa dans la VM peut être déclenchée par des sauvegardes à l'échelle de l'hôte, des scrubs ou des reconstructions - je corrige les temps avec les tâches de l'hôte avant de toucher à l'application.
Valeurs limites, seuils et prochaines étapes
Je décide à l'aide de quelques seuils clairs s'il existe un véritable goulot d'étranglement et quelle action doit être entreprise pour stabiliser sensiblement la performance. Je tiens compte du type de support, de la charge de travail et des exigences de latence, car les mêmes chiffres sur HDD et NVMe ont des implications différentes. Je prends le tableau suivant comme un garde-fou rapide que j'utilise dans mes playbooks. Je mesure plusieurs fois pendant des minutes et sous charge, afin que les valeurs aberrantes ne génèrent pas de fausses alertes et que je puisse identifier des tendances. Sur cette base, j'interviens de manière ciblée, au lieu de changer de matériel par réflexe ou de faire des économies. Paramètres augmenter massivement.
| Métriques | Seuil | interprétation | Prochaines étapes |
|---|---|---|---|
| wa (vmstat) | > 15-20% | Temps d'attente d'E/S significatif | Vérifier iostat ; trouver la cause avec pidstat/iotop ; examiner le cache et les écritures |
| %util (iostat) | > 80-90% | Appareil utilisé à pleine capacité | Corréler await/avgqu-sz ; vérifier la profondeur de la file d'attente, l'ordonnanceur, RAID et SSD/NVMe |
| await (ms) | > 10-20 ms SSD, > 30-50 ms HDD | Latence accrue | Différencier aléatoire et séquentiel ; options du système de fichiers, writeback, personnaliser le journalisation |
| avgqu-sz | > 1-2 persistant | La file d'attente s'allonge | Étrangler/augmenter le parallélisme ; optimiser les modèles d'E/S de l'application ; vérifier les limites du contrôleur |
| si/so (vmstat) | > 0 en charge | Goulot d'étranglement de la mémoire | Augmenter la RAM ; Réglage des requêtes/cache ; Vérifier le swappiness/les limites de mémoire |
Causes dans la pile : DB, système de fichiers, virtualisation
Pour les bases de données, je vois souvent des jointures non indexées, des buffers trop petits et des appels fsync excessifs comme étant les véritables problèmes. Causes pour des valeurs await élevées. Je vérifie les plans de requête, j'active les journaux pour les déclarations lentes et j'ajuste objectivement les tailles telles que le pool de tampons InnoDB, les tailles des fichiers journaux et les fichiers ouverts. Au niveau du système de fichiers, j'examine les options de montage, les modes de journalisation et l'alignement avec la bande RAID, car les mauvaises combinaisons font exploser les temps d'attente. Dans les configurations virtualisées, je ne me fie pas aux mesures dans la VM seule, mais j'observe l'hôte, car c'est là que se trouvent les véritables périphériques de bloc et les Queues de billard sont visibles. Ainsi, je sépare proprement les effets de la déduplication, du thin provisioning ou des VM voisines des modèles d'application.
Options de système de fichiers et de montage en détail
J'évalue les systèmes de fichiers à la lumière de la charge de travail : ext4 en mode ordered ou writeback minimise les barrières à l'intensité d'écriture, tandis que XFS marque des points dans les charges de travail parallèles grâce à sa conception de logs. Des options telles que noatime ou relatime réduisent les écritures de métadonnées, lazytime déplace les mises à jour d'horodatage vers le writeback en les regroupant. Pour le journalisation, je contrôle les intervalles de commit (par ex. commit=) et je vérifie si les forclusions (barrières) sont renforcées par les politiques de cache du contrôleur. Sur RAID, je veille à ce que l'alignement avec la bande soit propre (partid/FDISK avec un démarrage de 1MiB), sinon le nombre d'erreurs augmente. await par Read-Modify-Write, même pour les modèles prétendument séquentiels. Pour les bases de données, j'utilise souvent O_DIRECT ou des stratégies directes de log-flush - mais uniquement après mesure, car le cache du système de fichiers peut soulager la charge de lecture de manière spectaculaire si le working set y est adapté.
Tuning : du noyau à l'application
Je commence par des gains simples, par exemple l'indexation des requêtes, l'écriture par lots et une configuration judicieuse de la mise en commun des connexions, avant d'intervenir au niveau du système. Pour le writeback, j'ajuste vm.dirty_background_ratio, vm.dirty_ratio et vm.dirty_expire_centisecs de manière contrôlée afin que le système écrive de manière cohérente et génère moins de blocage sans encombrer la mémoire. Sur les périphériques en bloc, je contrôle le planificateur d'E/S, la profondeur de la file d'attente et le read-ahead, car ces vis de réglage façonnent directement la latence et le débit. Sur les contrôleurs RAID, je règle la taille des bandes et la politique de cache, alors que sur les SSD/NVMe pour le firmware, TRIM et les paramètres d'overprovisioning cohérents. Après chaque modification, je vérifie avec vmstat et iostat pendant plusieurs minutes que await tombe et que %util reste stable avant de passer à l'étape suivante.
Interruptions, NUMA et affinités
J'observe la charge de l'IRQ et la topologie du NUMA, car ces deux éléments ont une influence sensible sur les latences. NVMe-Je lie les interruptions aux CPU du domaine NUMA du contrôleur par affinité, afin que les chemins de données restent courts. Si la tempête d'IRQ se déroule sur un noyau, j'y vois de grandes quantités de données. sy et dans le reste de l'unité centrale, apparemment au ralenti ; mpstat le démasque. Je n'autorise irqbalance que si la distribution correspond au matériel - sinon, je place des affinités ciblées. De même, je vérifie si l'application et sa E/S travailler dans la même zone NUMA (localisation de la mémoire), car les accès cross-socket nécessitent des temps d'attente en await peuvent être masqués.
Automatiser la mesure et la rendre visible
Afin d'identifier les tendances avec certitude, j'automatise les mesures et j'intègre iostat/vmstat dans des outils de monitoring qui fournissent des données historiques. Données enregistrer les données. Je définis des alarmes de manière conservatrice, par exemple à partir de wa > 15% sur plusieurs intervalles, combinées à des seuils pour await et %util afin d'éviter les fausses alarmes. Pour les images globales des métriques, j'utilise des tableaux de bord qui juxtaposent les chiffres du CPU, du stockage, du réseau et des applications afin que les corrélations soient immédiatement visibles. Pour ceux qui ont besoin d'une introduction aux indicateurs, voir Métriques du serveur contexte compact pour le travail quotidien. Ce qui est important pour moi, c'est un processus répétable : mesurer, émettre une hypothèse, effectuer un ajustement, mesurer à nouveau et Résultats documenter.
Tests de charge reproductibles avec fio
Lorsque je manque de charge réelle ou que je veux vérifier des hypothèses, j'utilise des produits éphémères. fio-de test. Je simule des modèles représentatifs (par ex. 4k random read, 64k sequential write, profils mixtes 70/30) et je varie iodepth, pour modifier la fenêtre Sweet Spot entre await et le débit. Je sépare strictement les chemins de test des données productives et je note les conditions limites (système de fichiers, options de montage, ordonnanceur, profondeur de la file d'attente) afin de pouvoir classer correctement les résultats. Après le réglage, les mêmes tests interviennent comme contrôle de régression ; ce n'est que si await et %util cohérent, j'intègre les modifications dans la surface.
Reconnaître les erreurs : modèles typiques
Si j'observe un wa élevé avec un %util élevé et un avgqu-sz croissant, tout indique une saturation sur le Périphérique, donc de véritables limites physiques. Des valeurs await élevées avec un %util modéré indiquent plutôt des particularités du contrôleur ou de la mise en cache, telles que des barrières, des write-through ou des flushes sporadiques. Des valeurs si/so croissantes associées à des chutes dans le cache indiquent clairement un manque de RAM, qui gonfle artificiellement les E/S et renforce les temps d'attente. Si le disque reste discret, mais que l'application cadre de grandes écritures sync, je déplace le travail vers l'écriture asynchrone, le pipelining ou le Lot-mécanismes de sécurité. Dans les configurations de stockage NFS ou en réseau, je vérifie également la latence, le MTU, les retransmissions et la mise en cache côté serveur, car le temps de réseau est ici directement masqué en tant que temps d'attente des E/S.
NFS/iSCSI et stockage distribué
À l'adresse suivante : NFS et iSCSI, je distingue le chemin du périphérique et le chemin du réseau : iostat ne montre que ce que la couche de blocs voit - je détecte en outre les retransmissions, les latences et les problèmes de fenêtres via les métriques de réseau. élevé await en cas d'exposition modérée %util sur le périphérique de bloc virtuel est typique lorsque le réseau se bloque ou que le cache côté serveur se refroidit. Pour NFS, je vérifie les options de montage (rsize/wsize, proto, sync/async) et le côté serveur (threads, politiques d'exportation, cache), pour iSCSI les paramètres de session et de file d'attente. Je planifie des fenêtres de maintenance pour les tâches du serveur (scrubs, rebuilds, rebalancing) afin qu'elles ne saturent pas le stockage partagé aux heures de pointe et ainsi wa sur tous les clients.
Exemples pratiques : trois courts scénarios
Cluster de blogs avec pointes d'écriture
Aux heures de pointe, les commentaires et l'invalidation des caches augmentent, après quoi await et avgqu-sz augmentent considérablement dans iostat, tandis que %util reste collé à 95%. J'augmente doucement les paramètres de writeback, j'optimise l'invalidation du cache au niveau des chemins et je renforce la mémoire tampon du journal InnoDB afin de réduire le nombre de petites écritures de synchronisation. Ensuite, await baisse de manière mesurable, les valeurs bo restent élevées, mais wa baisse, ce qui réduit immédiatement les temps de réponse. Parallèlement, je remplace certains disques durs par des disques SSD pour le journal, ce qui me permet de soulager encore le goulot d'étranglement. Le schéma montre comment Lot-Combiner écriture et journal plus rapide.
Boutique avec pics de lecture et indices de recherche
Les promotions génèrent une forte charge de lecture, r/s s'envole, await reste modéré, mais l'application réagit quand même lentement à la navigation par filtre. Je détecte de nombreuses requêtes non mises en mémoire tampon sans index appropriés, qui font exploser le jeu de travail du cache du système de fichiers. Avec une indexation ciblée et une réécriture de requête, le r/s chute, les occurrences sont plus souvent dans le cache et iostat confirme des MB_read plus faibles pour un débit inchangé. En même temps, j'augmente légèrement le read-ahead pour servir plus efficacement les scans séquentiels, ce qui diminue encore les latences. Ainsi, je contrôle que Lire-Les modèles d'identification peuvent à nouveau conduire à des résultats de cache.
Hôte VM avec „Noisy Neighbor“
Dans certaines VM, top indique wa élevé, mais iostat dans la VM ne voit que des périphériques virtuels avec une charge trompeuse. J'effectue des mesures supplémentaires sur l'hyperviseur, je vois des périphériques en bloc réels saturés et j'identifie une VM voisine avec des sauvegardes agressives comme étant la cause. Grâce à des limites de bande passante et à des fenêtres de sauvegarde modifiées, await et %util se stabilisent dans tout l'hôte. Ensuite, je mesure à nouveau dans la VM et sur l'hôte afin de confirmer et de prévenir l'effet des deux côtés. Cela confirme que de véritables Appareils-Les métriques de l'hôte montrent toujours la vérité.
Liste de contrôle pour le prochain incident
Je lance d'abord les logs et les mesures pour ne pas perdre de signaux, et je maintiens vmstat 1 et iostat -x 1 en fonctionnement pendant plusieurs minutes. Ensuite, je corrèle les pics dans le temps avec les événements des applications et les temporisations du système, avant de fixer les processus individuels avec pidstat -d et de formuler des hypothèses. L'étape suivante consiste à vérifier la mémoire, le swap et les occurrences de cache, afin d'éviter qu'un manque de RAM ne soit considéré à tort comme un problème. disque-Le problème apparaît. Ce n'est que lorsque j'ai isolé le responsable que je modifie exactement une chose, que je consigne le réglage et que j'évalue l'effet sur await, %util et wa. Ainsi, je garde l'analyse reproductible, j'apprends de chaque incident et je réduis le temps jusqu'à la Solution clairement.
Fréquentes erreurs d'interprétation et pierres d'achoppement
Je ne suis pas dupe des pics isolés : Des secondes isolées avec un haut wa sont normales, seuls des plateaux persistants indiquent un goulot d'étranglement structurel. %util proche de 100% n'est critique que si await se déclenche en même temps - sinon, l'appareil est tout simplement bien occupé. Sur SSD/NVMe est plus élevé avgqu-sz souvent voulu pour utiliser le parallélisme interne ; je n'étrangle que lorsque les objectifs de latence ne sont pas atteints. Je vérifie la mise à l'échelle de la fréquence du CPU : une économie d'énergie agressive peut augmenter les temps de réaction et ainsi wa semblent s'aggraver. Et je sépare le TTFB applicatif de la latence de stockage - le réseau, les handshake TLS et les services en amont peuvent générer des symptômes similaires sans que iostat „est “coupable".
Bref résumé pour les admins
L'analyse de l'attente d'E/S avec iostat et vmstat est rapide si je lis wa, await, %util et avgqu-sz ensemble et si je les rapporte au contexte de la charge de travail. J'identifie d'abord s'il y a une véritable saturation de l'appareil ou si ce sont les modèles de mémoire et d'app qui entraînent la latence, puis je choisis le levier approprié. De petites adaptations ciblées des requêtes, des paramètres de writeback, du scheduler ou de la profondeur de la file d'attente produisent souvent le plus grand effet, avant qu'il ne soit nécessaire de procéder à des changements matériels coûteux. Mesure, hypothèse, modification et nouvelle mesure restent ma séquence fixe, afin que les décisions restent compréhensibles et répétables. C'est ainsi que je maintiens Linux-Le serveur de données est plus réactif et garantit une amélioration sensible de la qualité des données. Temps de réponse en charge.
