{"id":19334,"date":"2026-05-14T12:39:05","date_gmt":"2026-05-14T10:39:05","guid":{"rendered":"https:\/\/webhosting.de\/server-io-wait-analyse-iostat-vmstat-metrics-disk\/"},"modified":"2026-05-14T12:39:05","modified_gmt":"2026-05-14T10:39:05","slug":"serveur-io-wait-analyse-iostat-vmstat-metrics-disk","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/server-io-wait-analyse-iostat-vmstat-metrics-disk\/","title":{"rendered":"Analyse de l'attente I\/O du serveur avec iostat et vmstat : optimiser les m\u00e9triques du serveur Linux"},"content":{"rendered":"<p>Je montre \u00e9tape par \u00e9tape comment l'analyse I\/O Wait avec iostat et vmstat met en \u00e9vidence les goulots d'\u00e9tranglement et quelles sont les m\u00e9triques Linux Server qui comptent pour des temps de r\u00e9action rapides. Je fixe des seuils clairs, interpr\u00e8te des mod\u00e8les typiques et propose des mesures concr\u00e8tes pour l'optimisation de <strong>E\/S<\/strong> et <strong>CPU<\/strong> un.<\/p>\n\n<h2>Points centraux<\/h2>\n<ul>\n  <li><strong>iostat<\/strong> et <strong>vmstat<\/strong> fournissent une vue compl\u00e9mentaire de la charge de l'unit\u00e9 centrale et du stockage.<\/li>\n  <li><strong>wa<\/strong> sur le 15-20% et <strong>%util<\/strong> via le 80% montrent un goulot d'\u00e9tranglement d'E\/S.<\/li>\n  <li><strong>await<\/strong> et <strong>avgqu-sz<\/strong> expliquent la latence et les files d'attente.<\/li>\n  <li><strong>mpstat<\/strong> d\u00e9tecte les charges in\u00e9galement r\u00e9parties sur les c\u0153urs du processeur.<\/li>\n  <li><strong>Tuning<\/strong> va de <strong>MySQL<\/strong> aux param\u00e8tres du noyau et au stockage.<\/li>\n<\/ul>\n\n<h2>Que signifie I\/O Wait sur les serveurs Linux ?<\/h2>\n<p>Sous I\/O-Wait, le CPU attend sans rien faire parce qu'il est en attente de p\u00e9riph\u00e9riques de stockage ou de r\u00e9seau plus lents, ce qui est <strong>wa<\/strong>-dans des outils comme top ou vmstat. J'\u00e9value ce pourcentage comme le temps pendant lequel les threads se bloquent et les requ\u00eates se terminent plus tard, ce que les utilisateurs ressentent directement comme une inertie. Les valeurs sup\u00e9rieures \u00e0 10-20% indiquent souvent une saturation de la m\u00e9moire. <strong>Stockage<\/strong>-lorsque les disques durs, les baies RAID ou les montages NFS sont satur\u00e9s. Dans les configurations d'h\u00e9bergement avec des bases de donn\u00e9es, les requ\u00eates non index\u00e9es et les pics d'\u00e9criture s'ajoutent aux temps d'attente inutiles sur le serveur. <strong>disque<\/strong>. Les personnes qui souhaitent rafra\u00eechir les concepts trouveront des bases sous <a href=\"https:\/\/webhosting.de\/fr\/comprendre-lattente-de-s-resoudre-le-goulot-detranglement-de-la-memoire-optimisation\/\">Comprendre l'attente d'E\/S<\/a>, J'ai besoin d'un peu de temps avant de me rendre au cabinet.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/linux-server-io-8592.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>D\u00e9marrage rapide : lire correctement vmstat<\/h2>\n<p>Avec vmstat, je v\u00e9rifie en quelques secondes les principaux <strong>Linux<\/strong>-et j'identifie les premiers mod\u00e8les sans grand effort. L'appel vmstat 1 10 fournit dix instantan\u00e9s, dans lesquels je pr\u00eate une attention particuli\u00e8re aux colonnes wa (attente E\/S), bi\/bo (E\/S en bloc) et si\/so (\u00e9change). Des valeurs bo \u00e9lev\u00e9es associ\u00e9es \u00e0 une augmentation de wa indiquent pour moi de nombreux acc\u00e8s en \u00e9criture bloquants, ce qui indique souvent des limites de tampon ou des supports lents. Si si\/so reste \u00e0 z\u00e9ro, mais que wa augmente nettement, cela signifie qu'il s'agit d'une erreur pure. <strong>Stockage<\/strong>-limite de la m\u00e9moire. Dans les h\u00f4tes multi-core, je combine vmstat avec mpstat -P ALL 1, car la wait I\/O ne concerne souvent que quelques c\u0153urs et semble donc plus inoffensive en moyenne g\u00e9n\u00e9rale qu'elle ne l'est en r\u00e9alit\u00e9.<\/p>\n\n<h2>Image fine du CPU : us\/sy\/st, file d'attente d'ex\u00e9cution et changement de contexte<\/h2>\n<p>Avec vmstat et mpstat, je lis plus de <strong>wa<\/strong>Haute : Haute <strong>us<\/strong>-Les parts de march\u00e9 de l'industrie de l'informatique montrent un travail d'application \u00e0 forte charge de calcul, <strong>sy<\/strong> indique un travail du noyau\/pilote, par exemple lors d'une utilisation intensive <strong>E\/S<\/strong>. Dans les environnements virtualis\u00e9s, je prends en consid\u00e9ration <strong>st<\/strong> (steal) (vol) : Des valeurs st \u00e9lev\u00e9es signifient que la VM perd du temps de CPU, ce qui gonfle artificiellement les latences pour un mod\u00e8le d'E\/S identique. Je compare \u00e9galement la file d'attente d'ex\u00e9cution (<strong>r<\/strong> dans vmstat) avec le nombre de CPU : un r durablement sup\u00e9rieur au nombre de CPU indique une congestion au niveau du CPU, et non du <strong>Stockage<\/strong>. Beaucoup de changements de contexte (<strong>cs<\/strong>) en combinaison avec de petites \u00e9critures synchrones sont un indicateur des sch\u00e9mas d'E\/S Chatty. Ainsi, j'\u00e9vite de mal interpr\u00e9ter une p\u00e9nurie de CPU comme un probl\u00e8me d'E\/S.<\/p>\n\n<h2>Comprendre iostat en profondeur : les m\u00e9triques importantes<\/h2>\n<p>iostat -x 1 me fournit des donn\u00e9es \u00e9tendues <strong>disque<\/strong>-m\u00e9triques qui d\u00e9crivent proprement la latence, l'utilisation et les files d'attente. Je commence \u00e0 mesurer les pics de charge et je corr\u00e8le %util, await, svctm et avgqu-sz pour distinguer la cause de l'effet. Si %util monte \u00e0 90-100%, alors que await et avgqu-sz montent aussi, je vois une saturation de l'espace. <strong>Plaque<\/strong> ou un volume limit\u00e9. Si await affiche des valeurs \u00e9lev\u00e9es avec un %util mod\u00e9r\u00e9, je v\u00e9rifie les interf\u00e9rences dues \u00e0 la mise en cache, aux limites du contr\u00f4leur ou \u00e0 de grandes requ\u00eates isol\u00e9es. r\/s et w\/s apportent de la fr\u00e9quence \u00e0 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\u00e9di\u00e9es.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/linuxserveroptiokoni7553.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NVMe, SATA et RAID : ce que signifient %util, await et Queue-Depth<\/h2>\n<p>Je fais une stricte distinction entre les types de m\u00e9dias : <strong>HDD<\/strong> montrent des taux plus \u00e9lev\u00e9s <strong>await<\/strong>-Les valeurs de l'indice d'alcool\u00e9mie sont d\u00e9j\u00e0 faibles avec une queue de billard mod\u00e9r\u00e9e, car les mouvements de la t\u00eate dominent. <strong>SSD<\/strong>\/NVMe \u00e9voluent bien avec le parall\u00e9lisme, c'est pourquoi une plus grande <strong>avgqu-sz<\/strong> peut \u00eatre normal, tant que <strong>await<\/strong> reste dans les limites. Sur NVMe avec plusieurs files d'attente de soumission\/compl\u00e9tion, je lis %util avec plus de retenue : des p\u00e9riph\u00e9riques individuels peuvent d\u00e9j\u00e0 \u00eatre \u00e0 la limite \u00e0 60-70% si l'application ne g\u00e9n\u00e8re pas assez de parall\u00e9lisme ou si la profondeur de la file d'attente (<strong>nr_requ\u00eates<\/strong>, <strong>queue_depth<\/strong>) est trop petit. Dans le site <strong>RAID<\/strong> je v\u00e9rifie si des E\/S al\u00e9atoires dispers\u00e9es rencontrent des bandes de taille trop petite ; dans ce cas, les E\/S al\u00e9atoires augmentent. <strong>await<\/strong> et <strong>%util<\/strong> de mani\u00e8re in\u00e9gale sur les disques membres. C'est pourquoi je regarde l'iostat par p\u00e9riph\u00e9rique membre, et pas seulement sur le volume assembl\u00e9, afin de mettre en \u00e9vidence les points chauds. Pour les couches structur\u00e9es par des logs (par ex. Copy-on-Write), je m'attends \u00e0 des latences un peu plus \u00e9lev\u00e9es pour les \u00e9critures, mais je compense en agrandissant les fen\u00eatres de writeback ou en utilisant le batching c\u00f4t\u00e9 app.<\/p>\n\n<h2>Flux de travail de diagnostic pour des temps d'attente \u00e9lev\u00e9s<\/h2>\n<p>Je d\u00e9marre chaque analyse en parall\u00e8le avec vmstat 1 et iostat -x 1, afin de voir les \u00e9tats du CPU et du p\u00e9riph\u00e9rique de mani\u00e8re synchrone et de pouvoir les attribuer dans le temps. Ensuite, je v\u00e9rifie avec mpstat -P ALL 1 si certains c\u0153urs sont anormalement \u00e9lev\u00e9s. <strong>wa<\/strong> ce qui \u00e9vite des valeurs moyennes mal interpr\u00e9t\u00e9es. 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\u00e9bergement avec des bases de donn\u00e9es, je distingue d'abord les pics de lecture des pics d'\u00e9criture, car les strat\u00e9gies de retour en \u00e9criture et les mod\u00e8les fsync g\u00e9n\u00e8rent des sympt\u00f4mes tr\u00e8s diff\u00e9rents et permettent ainsi de cibler les pics de lecture. <strong>Mesures<\/strong> permettent d'y parvenir. Pour les questions de stockage plus approfondies, une vue d'ensemble comme celle de <a href=\"https:\/\/webhosting.de\/fr\/io-bottleneck-hebergement-analyse-de-la-latence-optimisation-du-stockage\/\">Bottleneck d'E\/S dans l'h\u00e9bergement<\/a>, J'ai besoin d'un peu de temps avant d'intervenir sur le noyau ou le syst\u00e8me de fichiers.<\/p>\n\n<h2>D\u00e9limiter proprement la virtualisation et les conteneurs<\/h2>\n<p>Dans les VM, je consid\u00e8re <strong>wa<\/strong> avec <strong>st<\/strong> (Steal) et mesure en plus sur l'hyperviseur, car c'est le seul endroit o\u00f9 les vrais appareils et les <strong>Queues de billard<\/strong> sont visibles. Les agr\u00e9gations de stockage (thin provisioning, dedupe, snapshots) d\u00e9placent les pics de latence vers le bas de la pile - dans la VM, cela fait alors effet <strong>await<\/strong> de fa\u00e7on spectaculaire, tandis que %util reste discret. Dans les conteneurs, je limite ou je d\u00e9couple <strong>E\/S<\/strong> avec des r\u00e8gles de Cgroup (par exemple, les limites IOPS\/Throughput) pour <strong>Voisins bruyants<\/strong> de l'apprivoiser. Je documente les limites par service afin que les valeurs mesur\u00e9es soient reproductibles et que les alarmes conservent leur contexte. Important : un niveau \u00e9lev\u00e9 <strong>wa<\/strong> dans la VM peut \u00eatre d\u00e9clench\u00e9e par des sauvegardes \u00e0 l'\u00e9chelle de l'h\u00f4te, des scrubs ou des reconstructions - je corrige les temps avec les t\u00e2ches de l'h\u00f4te avant de toucher \u00e0 l'application.<\/p>\n\n<h2>Valeurs limites, seuils et prochaines \u00e9tapes<\/h2>\n<p>Je d\u00e9cide \u00e0 l'aide de quelques seuils clairs s'il existe un v\u00e9ritable goulot d'\u00e9tranglement et quelle action doit \u00eatre 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\u00eames chiffres sur HDD et NVMe ont des implications diff\u00e9rentes. 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\u00e9n\u00e8rent pas de fausses alertes et que je puisse identifier des tendances. Sur cette base, j'interviens de mani\u00e8re cibl\u00e9e, au lieu de changer de mat\u00e9riel par r\u00e9flexe ou de faire des \u00e9conomies. <strong>Param\u00e8tres<\/strong> augmenter massivement.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>M\u00e9triques<\/th>\n      <th>Seuil<\/th>\n      <th>interpr\u00e9tation<\/th>\n      <th>Prochaines \u00e9tapes<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>wa<\/strong> (vmstat)<\/td>\n      <td>&gt; 15-20%<\/td>\n      <td>Temps d'attente d'E\/S significatif<\/td>\n      <td>V\u00e9rifier iostat ; trouver la cause avec pidstat\/iotop ; examiner le cache et les \u00e9critures<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>%util<\/strong> (iostat)<\/td>\n      <td>&gt; 80-90%<\/td>\n      <td>Appareil utilis\u00e9 \u00e0 pleine capacit\u00e9<\/td>\n      <td>Corr\u00e9ler await\/avgqu-sz ; v\u00e9rifier la profondeur de la file d'attente, l'ordonnanceur, RAID et SSD\/NVMe<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>await<\/strong> (ms)<\/td>\n      <td>&gt; 10-20 ms SSD, &gt; 30-50 ms HDD<\/td>\n      <td>Latence accrue<\/td>\n      <td>Diff\u00e9rencier al\u00e9atoire et s\u00e9quentiel ; options du syst\u00e8me de fichiers, writeback, personnaliser le journalisation<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>avgqu-sz<\/strong><\/td>\n      <td>&gt; 1-2 persistant<\/td>\n      <td>La file d'attente s'allonge<\/td>\n      <td>\u00c9trangler\/augmenter le parall\u00e9lisme ; optimiser les mod\u00e8les d'E\/S de l'application ; v\u00e9rifier les limites du contr\u00f4leur<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>si\/so<\/strong> (vmstat)<\/td>\n      <td>&gt; 0 en charge<\/td>\n      <td>Goulot d'\u00e9tranglement de la m\u00e9moire<\/td>\n      <td>Augmenter la RAM ; R\u00e9glage des requ\u00eates\/cache ; V\u00e9rifier le swappiness\/les limites de m\u00e9moire<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/server-metrics-optimization-8421.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Causes dans la pile : DB, syst\u00e8me de fichiers, virtualisation<\/h2>\n<p>Pour les bases de donn\u00e9es, je vois souvent des jointures non index\u00e9es, des buffers trop petits et des appels fsync excessifs comme \u00e9tant les v\u00e9ritables probl\u00e8mes. <strong>Causes<\/strong> pour des valeurs await \u00e9lev\u00e9es. Je v\u00e9rifie les plans de requ\u00eate, j'active les journaux pour les d\u00e9clarations 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\u00e8me 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\u00e9es, je ne me fie pas aux mesures dans la VM seule, mais j'observe l'h\u00f4te, car c'est l\u00e0 que se trouvent les v\u00e9ritables p\u00e9riph\u00e9riques de bloc et les <strong>Queues de billard<\/strong> sont visibles. Ainsi, je s\u00e9pare proprement les effets de la d\u00e9duplication, du thin provisioning ou des VM voisines des mod\u00e8les d'application.<\/p>\n\n<h2>Options de syst\u00e8me de fichiers et de montage en d\u00e9tail<\/h2>\n<p>J'\u00e9value les syst\u00e8mes de fichiers \u00e0 la lumi\u00e8re de la charge de travail : <strong>ext4<\/strong> en mode ordered ou writeback minimise les barri\u00e8res \u00e0 l'intensit\u00e9 d'\u00e9criture, tandis que <strong>XFS<\/strong> marque des points dans les charges de travail parall\u00e8les gr\u00e2ce \u00e0 sa conception de logs. Des options telles que <strong>noatime<\/strong> ou <strong>relatime<\/strong> r\u00e9duisent les \u00e9critures de m\u00e9tadonn\u00e9es, <strong>lazytime<\/strong> d\u00e9place les mises \u00e0 jour d'horodatage vers le writeback en les regroupant. Pour le journalisation, je contr\u00f4le les intervalles de commit (par ex. commit=) et je v\u00e9rifie si les forclusions (barri\u00e8res) sont renforc\u00e9es par les politiques de cache du contr\u00f4leur. Sur RAID, je veille \u00e0 ce que l'alignement avec la bande soit propre (partid\/FDISK avec un d\u00e9marrage de 1MiB), sinon le nombre d'erreurs augmente. <strong>await<\/strong> par Read-Modify-Write, m\u00eame pour les mod\u00e8les pr\u00e9tendument s\u00e9quentiels. Pour les bases de donn\u00e9es, j'utilise souvent O_DIRECT ou des strat\u00e9gies directes de log-flush - mais uniquement apr\u00e8s mesure, car le cache du syst\u00e8me de fichiers peut soulager la charge de lecture de mani\u00e8re spectaculaire si le working set y est adapt\u00e9.<\/p>\n\n<h2>Tuning : du noyau \u00e0 l'application<\/h2>\n<p>Je commence par des gains simples, par exemple l'indexation des requ\u00eates, l'\u00e9criture par lots et une configuration judicieuse de la mise en commun des connexions, avant d'intervenir au niveau du syst\u00e8me. Pour le writeback, j'ajuste vm.dirty_background_ratio, vm.dirty_ratio et vm.dirty_expire_centisecs de mani\u00e8re contr\u00f4l\u00e9e afin que le syst\u00e8me \u00e9crive de mani\u00e8re coh\u00e9rente et g\u00e9n\u00e8re moins de blocage sans encombrer la m\u00e9moire. Sur les p\u00e9riph\u00e9riques en bloc, je contr\u00f4le le planificateur d'E\/S, la profondeur de la file d'attente et le read-ahead, car ces vis de r\u00e9glage fa\u00e7onnent directement la latence et le d\u00e9bit. Sur les contr\u00f4leurs RAID, je r\u00e8gle la taille des bandes et la politique de cache, alors que sur les <strong>SSD<\/strong>\/NVMe pour le firmware, TRIM et les param\u00e8tres d'overprovisioning coh\u00e9rents. Apr\u00e8s chaque modification, je v\u00e9rifie avec vmstat et iostat pendant plusieurs minutes que await tombe et que %util reste stable avant de passer \u00e0 l'\u00e9tape suivante.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/TechOfficeServerAnalyse4102.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Interruptions, NUMA et affinit\u00e9s<\/h2>\n<p>J'observe la charge de l'IRQ et la topologie du NUMA, car ces deux \u00e9l\u00e9ments ont une influence sensible sur les latences. <strong>NVMe<\/strong>-Je lie les interruptions aux CPU du domaine NUMA du contr\u00f4leur par affinit\u00e9, afin que les chemins de donn\u00e9es restent courts. Si la temp\u00eate d'IRQ se d\u00e9roule sur un noyau, j'y vois de grandes quantit\u00e9s de donn\u00e9es. <strong>sy<\/strong> et dans le reste de l'unit\u00e9 centrale, apparemment au ralenti ; <strong>mpstat<\/strong> le d\u00e9masque. Je n'autorise irqbalance que si la distribution correspond au mat\u00e9riel - sinon, je place des affinit\u00e9s cibl\u00e9es. De m\u00eame, je v\u00e9rifie si l'application et sa <strong>E\/S<\/strong> travailler dans la m\u00eame zone NUMA (localisation de la m\u00e9moire), car les acc\u00e8s cross-socket n\u00e9cessitent des temps d'attente en <strong>await<\/strong> peuvent \u00eatre masqu\u00e9s.<\/p>\n\n<h2>Automatiser la mesure et la rendre visible<\/h2>\n<p>Afin d'identifier les tendances avec certitude, j'automatise les mesures et j'int\u00e8gre iostat\/vmstat dans des outils de monitoring qui fournissent des donn\u00e9es historiques. <strong>Donn\u00e9es<\/strong> enregistrer les donn\u00e9es. Je d\u00e9finis des alarmes de mani\u00e8re conservatrice, par exemple \u00e0 partir de wa &gt; 15% sur plusieurs intervalles, combin\u00e9es \u00e0 des seuils pour await et %util afin d'\u00e9viter les fausses alarmes. Pour les images globales des m\u00e9triques, j'utilise des tableaux de bord qui juxtaposent les chiffres du CPU, du stockage, du r\u00e9seau et des applications afin que les corr\u00e9lations soient imm\u00e9diatement visibles. Pour ceux qui ont besoin d'une introduction aux indicateurs, voir <a href=\"https:\/\/webhosting.de\/fr\/metriques-serveur-cpu-idle-load-wait-analyse-serverboost\/\">M\u00e9triques du serveur<\/a> contexte compact pour le travail quotidien. Ce qui est important pour moi, c'est un processus r\u00e9p\u00e9table : mesurer, \u00e9mettre une hypoth\u00e8se, effectuer un ajustement, mesurer \u00e0 nouveau et <strong>R\u00e9sultats<\/strong> documenter.<\/p>\n\n<h2>Tests de charge reproductibles avec fio<\/h2>\n<p>Lorsque je manque de charge r\u00e9elle ou que je veux v\u00e9rifier des hypoth\u00e8ses, j'utilise des produits \u00e9ph\u00e9m\u00e8res. <strong>fio<\/strong>-de test. Je simule des mod\u00e8les repr\u00e9sentatifs (par ex. 4k random read, 64k sequential write, profils mixtes 70\/30) et je varie <strong>iodepth<\/strong>, pour modifier la fen\u00eatre Sweet Spot entre <strong>await<\/strong> et le d\u00e9bit. Je s\u00e9pare strictement les chemins de test des donn\u00e9es productives et je note les conditions limites (syst\u00e8me de fichiers, options de montage, ordonnanceur, profondeur de la file d'attente) afin de pouvoir classer correctement les r\u00e9sultats. Apr\u00e8s le r\u00e9glage, les m\u00eames tests interviennent comme contr\u00f4le de r\u00e9gression ; ce n'est que si <strong>await<\/strong> et <strong>%util<\/strong> coh\u00e9rent, j'int\u00e8gre les modifications dans la surface.<\/p>\n\n<h2>Reconna\u00eetre les erreurs : mod\u00e8les typiques<\/h2>\n<p>Si j'observe un wa \u00e9lev\u00e9 avec un %util \u00e9lev\u00e9 et un avgqu-sz croissant, tout indique une saturation sur le <strong>P\u00e9riph\u00e9rique<\/strong>, donc de v\u00e9ritables limites physiques. Des valeurs await \u00e9lev\u00e9es avec un %util mod\u00e9r\u00e9 indiquent plut\u00f4t des particularit\u00e9s du contr\u00f4leur ou de la mise en cache, telles que des barri\u00e8res, des write-through ou des flushes sporadiques. Des valeurs si\/so croissantes associ\u00e9es \u00e0 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 \u00e9critures sync, je d\u00e9place le travail vers l'\u00e9criture asynchrone, le pipelining ou le <strong>Lot<\/strong>-m\u00e9canismes de s\u00e9curit\u00e9. Dans les configurations de stockage NFS ou en r\u00e9seau, je v\u00e9rifie \u00e9galement la latence, le MTU, les retransmissions et la mise en cache c\u00f4t\u00e9 serveur, car le temps de r\u00e9seau est ici directement masqu\u00e9 en tant que temps d'attente des E\/S.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/server_metrics_analysis_1423.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NFS\/iSCSI et stockage distribu\u00e9<\/h2>\n<p>\u00c0 l'adresse suivante : <strong>NFS<\/strong> et iSCSI, je distingue le chemin du p\u00e9riph\u00e9rique et le chemin du r\u00e9seau : <strong>iostat<\/strong> ne montre que ce que la couche de blocs voit - je d\u00e9tecte en outre les retransmissions, les latences et les probl\u00e8mes de fen\u00eatres via les m\u00e9triques de r\u00e9seau. \u00e9lev\u00e9 <strong>await<\/strong> en cas d'exposition mod\u00e9r\u00e9e <strong>%util<\/strong> sur le p\u00e9riph\u00e9rique de bloc virtuel est typique lorsque le r\u00e9seau se bloque ou que le cache c\u00f4t\u00e9 serveur se refroidit. Pour NFS, je v\u00e9rifie les options de montage (rsize\/wsize, proto, sync\/async) et le c\u00f4t\u00e9 serveur (threads, politiques d'exportation, cache), pour iSCSI les param\u00e8tres de session et de file d'attente. Je planifie des fen\u00eatres de maintenance pour les t\u00e2ches du serveur (scrubs, rebuilds, rebalancing) afin qu'elles ne saturent pas le stockage partag\u00e9 aux heures de pointe et ainsi <strong>wa<\/strong> sur tous les clients.<\/p>\n\n<h2>Exemples pratiques : trois courts sc\u00e9narios<\/h2>\n<h3>Cluster de blogs avec pointes d'\u00e9criture<\/h3>\n<p>Aux heures de pointe, les commentaires et l'invalidation des caches augmentent, apr\u00e8s quoi await et avgqu-sz augmentent consid\u00e9rablement dans iostat, tandis que %util reste coll\u00e9 \u00e0 95%. J'augmente doucement les param\u00e8tres de writeback, j'optimise l'invalidation du cache au niveau des chemins et je renforce la m\u00e9moire tampon du journal InnoDB afin de r\u00e9duire le nombre de petites \u00e9critures de synchronisation. Ensuite, await baisse de mani\u00e8re mesurable, les valeurs bo restent \u00e9lev\u00e9es, mais wa baisse, ce qui r\u00e9duit imm\u00e9diatement les temps de r\u00e9ponse. Parall\u00e8lement, je remplace certains disques durs par des disques SSD pour le journal, ce qui me permet de soulager encore le goulot d'\u00e9tranglement. Le sch\u00e9ma montre comment <strong>Lot<\/strong>-Combiner \u00e9criture et journal plus rapide.<\/p>\n<h3>Boutique avec pics de lecture et indices de recherche<\/h3>\n<p>Les promotions g\u00e9n\u00e8rent une forte charge de lecture, r\/s s'envole, await reste mod\u00e9r\u00e9, mais l'application r\u00e9agit quand m\u00eame lentement \u00e0 la navigation par filtre. Je d\u00e9tecte de nombreuses requ\u00eates non mises en m\u00e9moire tampon sans index appropri\u00e9s, qui font exploser le jeu de travail du cache du syst\u00e8me de fichiers. Avec une indexation cibl\u00e9e et une r\u00e9\u00e9criture de requ\u00eate, le r\/s chute, les occurrences sont plus souvent dans le cache et iostat confirme des MB_read plus faibles pour un d\u00e9bit inchang\u00e9. En m\u00eame temps, j'augmente l\u00e9g\u00e8rement le read-ahead pour servir plus efficacement les scans s\u00e9quentiels, ce qui diminue encore les latences. Ainsi, je contr\u00f4le que <strong>Lire<\/strong>-Les mod\u00e8les d'identification peuvent \u00e0 nouveau conduire \u00e0 des r\u00e9sultats de cache.<\/p>\n<h3>H\u00f4te VM avec \u201eNoisy Neighbor\u201c<\/h3>\n<p>Dans certaines VM, top indique wa \u00e9lev\u00e9, mais iostat dans la VM ne voit que des p\u00e9riph\u00e9riques virtuels avec une charge trompeuse. J'effectue des mesures suppl\u00e9mentaires sur l'hyperviseur, je vois des p\u00e9riph\u00e9riques en bloc r\u00e9els satur\u00e9s et j'identifie une VM voisine avec des sauvegardes agressives comme \u00e9tant la cause. Gr\u00e2ce \u00e0 des limites de bande passante et \u00e0 des fen\u00eatres de sauvegarde modifi\u00e9es, await et %util se stabilisent dans tout l'h\u00f4te. Ensuite, je mesure \u00e0 nouveau dans la VM et sur l'h\u00f4te afin de confirmer et de pr\u00e9venir l'effet des deux c\u00f4t\u00e9s. Cela confirme que de v\u00e9ritables <strong>Appareils<\/strong>-Les m\u00e9triques de l'h\u00f4te montrent toujours la v\u00e9rit\u00e9.<\/p>\n\n<h2>Liste de contr\u00f4le pour le prochain incident<\/h2>\n<p>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\u00e8le les pics dans le temps avec les \u00e9v\u00e9nements des applications et les temporisations du syst\u00e8me, avant de fixer les processus individuels avec pidstat -d et de formuler des hypoth\u00e8ses. L'\u00e9tape suivante consiste \u00e0 v\u00e9rifier la m\u00e9moire, le swap et les occurrences de cache, afin d'\u00e9viter qu'un manque de RAM ne soit consid\u00e9r\u00e9 \u00e0 tort comme un probl\u00e8me. <strong>disque<\/strong>-Le probl\u00e8me appara\u00eet. Ce n'est que lorsque j'ai isol\u00e9 le responsable que je modifie exactement une chose, que je consigne le r\u00e9glage et que j'\u00e9value l'effet sur await, %util et wa. Ainsi, je garde l'analyse reproductible, j'apprends de chaque incident et je r\u00e9duis le temps jusqu'\u00e0 la <strong>Solution<\/strong> clairement.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/serveranalyse-linuxmetrics-4581.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Fr\u00e9quentes erreurs d'interpr\u00e9tation et pierres d'achoppement<\/h2>\n<p>Je ne suis pas dupe des pics isol\u00e9s : Des secondes isol\u00e9es avec un haut <strong>wa<\/strong> sont normales, seuls des plateaux persistants indiquent un goulot d'\u00e9tranglement structurel. <strong>%util<\/strong> proche de 100% n'est critique que si <strong>await<\/strong> se d\u00e9clenche en m\u00eame temps - sinon, l'appareil est tout simplement bien occup\u00e9. Sur <strong>SSD<\/strong>\/NVMe est plus \u00e9lev\u00e9 <strong>avgqu-sz<\/strong> souvent voulu pour utiliser le parall\u00e9lisme interne ; je n'\u00e9trangle que lorsque les objectifs de latence ne sont pas atteints. Je v\u00e9rifie la mise \u00e0 l'\u00e9chelle de la fr\u00e9quence du CPU : une \u00e9conomie d'\u00e9nergie agressive peut augmenter les temps de r\u00e9action et ainsi <strong>wa<\/strong> semblent s'aggraver. Et je s\u00e9pare le TTFB applicatif de la latence de stockage - le r\u00e9seau, les handshake TLS et les services en amont peuvent g\u00e9n\u00e9rer des sympt\u00f4mes similaires sans que <strong>iostat<\/strong> \u201eest \u201ccoupable\".<\/p>\n\n<h2>Bref r\u00e9sum\u00e9 pour les admins<\/h2>\n<p>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\u00e9ritable saturation de l'appareil ou si ce sont les mod\u00e8les de m\u00e9moire et d'app qui entra\u00eenent la latence, puis je choisis le levier appropri\u00e9. De petites adaptations cibl\u00e9es des requ\u00eates, des param\u00e8tres 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\u00e9cessaire de proc\u00e9der \u00e0 des changements mat\u00e9riels co\u00fbteux. Mesure, hypoth\u00e8se, modification et nouvelle mesure restent ma s\u00e9quence fixe, afin que les d\u00e9cisions restent compr\u00e9hensibles et r\u00e9p\u00e9tables. C'est ainsi que je maintiens <strong>Linux<\/strong>-Le serveur de donn\u00e9es est plus r\u00e9actif et garantit une am\u00e9lioration sensible de la qualit\u00e9 des donn\u00e9es. <strong>Temps de r\u00e9ponse<\/strong> en charge.<\/p>","protected":false},"excerpt":{"rendered":"<p>Analyse de l'attente I\/O du serveur avec iostat et vmstat : optimiser linux server metrics pour une performance maximale dans l'h\u00e9bergement.<\/p>","protected":false},"author":1,"featured_media":19327,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[780],"tags":[],"class_list":["post-19334","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"55","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"I\/O Wait Analyse","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"19327","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/19334","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/comments?post=19334"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/19334\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/19327"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=19334"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=19334"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=19334"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}