Analyser les performances disques sous Linux

Un service rame et vous soupçonnez le disque ? Avant de conclure, il faut mesurer. Ce guide montre comment évaluer les trois indicateurs qui comptent vraiment (débit, IOPS, latence) avec fio et iostat, vérifier la santé du matériel avec smartctl, et surtout interpréter les résultats sans tomber dans le piège du cache ou d'un test trop court. Il s'adresse aux administrateurs intermédiaires à avancés sur Linux (Debian, Ubuntu, RHEL).

Ce que vous allez apprendre

• Distinguer débit, IOPS et latence, et savoir lequel regarder
• Mesurer les performances réelles d'un disque avec fio
• Observer l'activité en direct avec iostat et iotop
• Éviter les conclusions hâtives (cache, test trop court, %util trompeur)

Prérequis

• Une machine Linux avec un compte sudo
• Les outils fio, sysstat (pour iostat) et smartmontools installés
• Comprendre la notion de système de fichiers et de montage

Debian / Ubuntu

sudo apt install fio sysstat smartmontools

RHEL / Fedora

sudo dnf install fio sysstat smartmontools

Débit, IOPS, latence : les trois métriques

La première erreur est de parler de « vitesse » du disque comme d'un chiffre unique. Trois grandeurs différentes décrivent un stockage, et un service lent ne souffre presque jamais des trois à la fois.

Métrique	Ce qu'elle mesure	Quand elle compte
Débit (throughput, Mo/s)	volume transféré par seconde	gros fichiers, sauvegardes, vidéo
IOPS	nombre d'opérations par seconde	bases de données, nombreux petits fichiers
Latence (await, ms ou µs)	temps de réponse d'une opération	ressenti utilisateur, applications interactives

Glissez pour voir

Le type de disque change radicalement les ordres de grandeur. Un disque dur (HDD) plafonne vers 100-200 IOPS à cause de la tête mécanique ; un SSD SATA atteint des dizaines de milliers d'IOPS ; un NVMe dépasse le million. Comparer la latence d'un NVMe (quelques µs) à celle d'un HDD (plusieurs ms) n'a pas de sens : ce sont des mondes différents.

Le bon réflexe

Une base de données lente est presque toujours un problème d'IOPS ou de latence, pas de débit. Mesurer le débit séquentiel d'un SSD pour diagnostiquer une base lente est une perte de temps : regardez les IOPS aléatoires et l'await.

Vérifier la santé avant de mesurer

Inutile de benchmarker un disque mourant. smartctl (paquet smartmontools) lit les données S.M.A.R.T. que le disque tient sur lui-même :

sudo smartctl -a /dev/sda

Trois attributs alertent sur une fin de vie proche :

• Reallocated_Sector_Ct : secteurs défectueux déjà remplacés.
• Current_Pending_Sector : secteurs instables en attente de réallocation.
• Wear_Leveling_Count (SSD) : usure des cellules mémoire.

Un compteur qui grimpe est un signal de remplacement. Lancez aussi un autotest non destructif :

sudo smartctl -t short /dev/sda     # test court (quelques minutes)
sudo smartctl -l selftest /dev/sda  # lire le résultat

Observer l'activité réelle avec iostat

iostat (paquet sysstat) montre ce que font les disques en direct. C'est l'outil pour voir si un disque est saturé pendant que le problème se produit :

iostat -dx 1

L'option -d cible les disques, -x ajoute les colonnes étendues, et 1 rafraîchit chaque seconde. Voici un extrait des colonnes clés (la sortie complète en comporte d'autres) :

Device   r/s     rkB/s    r_await   w/s     wkB/s    w_await   aqu-sz   %util
dm-0     55.93   1167.49   0.69      30.58   493.59    1.29      0.08     1.55

Ce qu'il faut lire :

• r/s et w/s : opérations de lecture et d'écriture par seconde (les IOPS réels).
• rkB/s et wkB/s : le débit en lecture et écriture.
• r_await et w_await : la latence moyenne en millisecondes, distinguée par sens. C'est l'indicateur le plus parlant d'un goulot.
• aqu-sz : taille moyenne de la file d'attente ; élevée, elle révèle un disque débordé.
• %util : pourcentage de temps occupé.

svctm et %util ne veulent plus dire grand-chose

Les anciens guides citent svctm et lisent %util à 100 % comme « disque saturé ». Sur sysstat 12+, la colonne svctm a disparu car elle était trompeuse. Et sur un SSD ou NVMe, %util proche de 100 % ne signifie pas la saturation : ces disques traitent plusieurs requêtes en parallèle, donc « occupé » ne veut pas dire « débordé ». Fiez-vous à l'await et à l'aqu-sz, pas au seul %util.

Pour savoir quel processus génère les I/O, iotop liste les coupables en temps réel :

sudo iotop -oP

L'option -o masque les processus inactifs, -P regroupe par processus. C'est ainsi qu'on repère un service de logs ou une sauvegarde qui écrase le disque.

Benchmarker avec fio

iostat observe la charge réelle ; fio (Flexible I/O tester) la provoque de façon contrôlée pour mesurer ce dont le disque est capable. C'est l'outil de référence du benchmark de stockage.

Tester sur un fichier, jamais sur un disque en service

fio peut écrire directement sur un périphérique brut (--filename=/dev/sdX), ce qui détruit les données. Pour un test sûr, pointez toujours sur un fichier dans un répertoire monté (--directory), comme ci-dessous.

Pour mesurer les IOPS aléatoires en 4 ko, le cas critique des bases de données :

fio --name=randread --directory=/var/tmp --rw=randread \
    --bs=4k --size=1G --runtime=30 --time_based \
    --ioengine=libaio --direct=1 --group_reporting

read: IOPS=19.8k, BW=77.5MiB/s (81.3MB/s)(465MiB/6001msec)
  lat (usec): min=20, max=1128, avg=49.62, stdev=15.00

La ligne donne tout : 19 800 IOPS, un débit de 77,5 Mio/s, et une latence moyenne de 50 µs. Pour mesurer le débit séquentiel (gros transferts), changez le motif et la taille de bloc :

fio --name=seqread --directory=/var/tmp --rw=read \
    --bs=1M --size=2G --runtime=30 --time_based \
    --ioengine=libaio --direct=1 --group_reporting

read: IOPS=1900, BW=1900MiB/s (1992MB/s)(11.1GiB/6001msec)

Les paramètres décisifs : --rw (randread, randwrite, read, write, randrw), --bs (4k pour de l'aléatoire, 1M pour du séquentiel), et surtout --direct=1, expliqué juste après.

Éviter les conclusions trop rapides

C'est ici que la plupart des analyses dérapent. Quatre pièges classiques.

Le cache fausse tout. Sans --direct=1, vous mesurez surtout la RAM, pas le disque : Linux sert les lectures depuis son cache de pages. Un dd naïf affiche des Go/s flatteurs qui ne reflètent rien :

# Trompeur : lit/écrit dans le cache
dd if=/dev/zero of=/var/tmp/test bs=1M count=1024
# Plus honnête : force l'écriture physique
dd if=/dev/zero of=/var/tmp/test bs=1M count=1024 oflag=direct

Avec fio, le --direct=1 contourne le cache : c'est non négociable pour mesurer le disque lui-même.

Un test trop court ment. Quelques secondes mesurent un pic, pas la tenue dans la durée. Un SSD bon départ peut s'effondrer une fois son cache SLC saturé. Utilisez --runtime=30 --time_based au minimum.

%util à 100 % n'est pas une preuve sur SSD/NVMe, comme vu plus haut : regardez la latence.

Mesurer à vide n'a pas de sens. Le seul test qui compte, c'est sous une charge proche du réel : même type d'accès (aléatoire ou séquentiel), même taille de bloc que votre application.

Reproduire ce guide

Tout est testable sans risque sur un fichier : fio sur /var/tmp ne touche aucune donnée. Lancez les deux commandes fio ci-dessus sur votre machine et comparez vos IOPS aléatoires (4k) à votre débit séquentiel (1M) : l'écart entre les deux dit tout sur la nature de votre stockage.

Dépannage

Symptôme	Cause probable	Piste de résolution
await élevé (> 20 ms sur SSD)	disque saturé ou défaillant	vérifier smartctl, répartir la charge I/O
%util à 100 % mais appli lente	faux positif sur SSD/NVMe parallèle	regarder await et aqu-sz, pas %util
IOPS très bas en aléatoire	HDD, ou cache désactivé attendu	comparer au type de disque, vérifier --direct
Débit fio irréaliste (Go/s)	cache non contourné	ajouter --direct=1
Un seul processus sature le disque	service mal réglé (logs, backup)	identifier via iotop -oP, ajuster sa cadence

Glissez pour voir

Matériel pour pratiquer

Pour mesurer de vraies performances NVMe avec fio, le Samsung 990 Pro est une référence (débit séquentiel élevé, IOPS aléatoires soutenues) idéale pour reproduire les tests de ce guide.

Lien affilié Amazon. Acheter via ce lien soutient le site sans surcoût pour vous.

Mettre en pratique

Après la mesure, l'optimisation : un volume très lu gaspille des I/O à écrire les dates d'accès. Dans ce lab, vous ajoutez l'option noatime sur un montage sollicité en lecture, l'activez à chaud et l'inscrivez dans /etc/fstab pour que le réglage de performance reste en place après un redémarrage.

Lab pratique

Optimiser un montage avec noatime de façon persistante

$ dsoxlab run l2-storage-performance

Environnement : VM·Durée : ~20 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/linux-dsoxlab-training.git
cd linux-dsoxlab-training

Lancer ce lab, puis valider votre travail :

dsoxlab run l2-storage-performance
dsoxlab check l2-storage-performance

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• Trois métriques distinctes : débit (Mo/s), IOPS, latence (await). Une base lente = IOPS/latence, pas débit.
• fio mesure ce dont le disque est capable ; iostat observe la charge réelle.
• --direct=1 est indispensable : sans lui, vous mesurez le cache, pas le disque.
• Sur SSD/NVMe, %util à 100 % ne prouve rien ; svctm a disparu de sysstat 12.
• Vérifiez la santé S.M.A.R.T. avant de benchmarker, et testez sur un fichier, jamais sur un disque en service.

Pour aller plus loin

• Surveiller un système avec Glances : Vue d'ensemble temps réel CPU, mémoire et disque.

×

📖 Voir la documentation →