Charge disque : iostat et iotop

Le disque est la cause la plus fréquente du « tout est lent mais le processeur est inactif ». Les processus attendent des entrées/sorties, la charge moyenne grimpe, mais htop affiche un CPU% proche de zéro. Voyons comment le constater en chiffres.

Ce qui vous est alloué

Les disques des nœuds sont des NVMe, mais la vitesse est plafonnée par grade : en écriture — 60 Mo/s par cœur, sans descendre sous 60 ni dépasser 400 Mo/s ; en lecture, le double de la vitesse d'écriture. Au-delà du plafond, un burst trois fois supérieur est autorisé pendant 30 secondes — de quoi décompresser une archive ou compiler un projet, mais pas d'envoyer un téraoctet en continu.

Si vos mesures tombent exactement sur ces valeurs, vous avez atteint le plafond — rien n'est cassé. Au-delà, seul le passage à un grade supérieur aide.

iostat : vue d'ensemble

apt install -y sysstat       # Debian, Ubuntu
dnf install -y sysstat       # AlmaLinux, CentOS Stream

iostat -xz 2

La commande affiche un instantané toutes les deux secondes. La première sortie est la moyenne depuis le démarrage — ignorez-la. Regardez la ligne vda ou sda :

• r/s, w/s — opérations de lecture et d'écriture par seconde.
• rkB/s, wkB/s — des mégaoctets, divisez par 1024. Comparez avec le tableau ci-dessus.
• await — attente moyenne par opération en millisecondes. Un chiffre unique est normal ; des dizaines et des centaines signalent une file d'attente.
• %util — taux d'occupation du disque. Un 90–100 % constant signifie que vous avez atteint le mur.

vmstat 2 est utile aussi : la colonne wa (attente E/S) indique, en pourcentage, le temps que le processeur passe simplement à attendre le disque.

iotop : qui écrit exactement

apt install -y iotop && iotop -oPa

-o n'affiche que les processus actifs, -P affiche les processus plutôt que les threads, -a affiche le volume cumulé depuis le lancement. Après une minute d'observation, vous verrez le vrai coupable : généralement une base de données, un collecteur de journaux ou une sauvegarde.

Une vérification ponctuelle sans l'interface interactive :

iotop -boPan 3 | head -20

Que faire selon ce que vous trouvez

• Le journal écrit. Limitez sa taille : journalctl --vacuum-size=200M et SystemMaxUse=200M dans /etc/systemd/journald.conf. Pour en savoir plus, consultez journaux systemd.
• La base de données écrit. Vérifiez si un parcours complet de table s'exécute à cause d'un index manquant, et si le buffer est trop petit, ce qui force tout sur le disque.
• Une sauvegarde ou rsync pendant les heures de travail. Limitez la vitesse : rsync --bwlimit=20M ; pour l'archivage, utilisez ionice -c3 nice -n19 tar ... afin que la tâche cède la priorité.
• Le swap. Si le disque est occupé par la pagination, le problème n'est pas le disque mais la mémoire — lisez Mémoire et swap.

Erreurs courantes

Mesurer la vitesse avec dd et conv=fdatasync et tirer des conclusions d'une seule exécution : les premières secondes profitent du burst et donnent un résultat gonflé. La méthodologie correcte se trouve dans Benchmark de la vitesse du disque et du réseau.

Un disque plein ressemble aussi à « tout est lent » : il n'y a plus d'espace libre, un service ne peut pas écrire de fichier temporaire et se bloque. Vérifiez df -h en premier — cela prend une seconde.