Vmstat sous Linux : RAM saturée, CPU ou disque ?

Un serveur ralentit, mais top ne montre pas toujours un processus bloqué à 100 %. Avec vmstat, vous pouvez voir en quelques secondes si les tâches attendent le processeur, le disque ou la mémoire. À condition de ne pas tirer de conclusion depuis la première ligne.

Je pars toujours sur plusieurs échantillons, puis je croise les compteurs avec free, iostat et les processus. C’est le seul moyen de distinguer une vraie pression mémoire d’un CPU chargé ou d’un stockage qui répond mal.

Lancer vmstat sur plusieurs échantillons

vmstat appartient généralement au paquet procps ou procps-ng. Commencez par un relevé toutes les secondes, avec six lignes au total :

vmstat 1 6

La première ligne résume l’activité depuis le démarrage. Elle ne décrit pas précisément la seconde qui vient de s’écouler. Pour diagnostiquer un ralentissement en cours, lisez surtout les lignes suivantes. L’option -w élargit les colonnes si les valeurs deviennent difficiles à lire :

vmstat -w 1 6

Gardez aussi un second terminal ouvert. Lancez le relevé, reproduisez l’action lente, puis notez les colonnes qui évoluent au même moment. Un pic isolé pendant une sauvegarde ou une compilation n’a pas le même poids qu’une file d’attente qui reste haute pendant plusieurs minutes.

Lire r, b et les colonnes CPU ensemble

Dans le groupe procs, r indique le nombre de tâches exécutables qui tournent ou attendent du temps processeur. Comparez cette valeur au nombre de processeurs logiques :

nproc
uptime

Si r reste nettement au-dessus du nombre de CPU disponibles et que us ou sy sont élevés, la machine manque probablement de temps processeur. us correspond au code exécuté en espace utilisateur, tandis que sy mesure le travail du noyau. Une valeur sy inhabituellement haute peut venir d’un grand nombre d’appels système, d’interruptions ou de changements de contexte.

La colonne b compte les tâches bloquées dans un sommeil non interruptible, souvent en attente d’une entrée-sortie. Si b monte avec wa, regardez le stockage avant d’accuser le CPU. wa représente du temps pendant lequel le processeur est inactif alors qu’une opération d’entrée-sortie est en attente.

• id : temps CPU inactif ;
• wa : attente d’entrée-sortie ;
• st : temps pris par l’hyperviseur sur une machine virtuelle.

Sur un VPS, un st répété peut signaler un hôte physique trop sollicité. Sur une machine physique, cette colonne reste normalement à zéro. Le guide sur le load average sous Linux complète cette lecture, car la charge inclut aussi certaines tâches bloquées et ne se réduit pas à un pourcentage CPU.

Reconnaître une vraie pression mémoire avec si et so

Les colonnes swpd, free, buff et cache donnent une vue compacte de la mémoire. Elles ne suffisent pas pour annoncer une saturation. Linux réutilise une partie de la RAM comme cache, et free dans vmstat ne remplace pas la colonne available de la commande free.

free -h
swapon --show

swpd indique la quantité de swap utilisée. Une valeur non nulle ne prouve pas que le système échange encore des pages. Regardez surtout si et so sur les échantillons récents :

• si : données relues depuis la swap vers la RAM ;
• so : données déplacées de la RAM vers la swap.

Des valeurs répétées dans si ou so, une mémoire available durablement basse et des temps de réponse dégradés forment un signal solide de pression mémoire. Une ancienne zone de swap occupée, sans échange actuel, n’a pas la même signification. Le guide sur free et la RAM disponible détaille le rôle du cache, tandis que l’article sur la swap sous Linux explique pourquoi il ne faut pas la vider par réflexe.

Confirmer une attente disque avec bi, bo et iostat

Dans la section io, bi et bo représentent les blocs reçus et envoyés par seconde. Ils montrent une activité globale, mais pas le périphérique responsable ni son temps de réponse. Si b et wa restent élevés, passez à iostat :

iostat -xz 1 5

Regardez notamment await, la file d’attente et %util pour chaque disque. Ne vous fiez pas à un seuil unique : un SSD NVMe peut traiter plusieurs opérations en parallèle, alors qu’un disque dur se dégrade vite avec des accès aléatoires. Comparez les valeurs au comportement habituel de la machine et au traitement en cours.

L’article sur iostat sous Linux explique comment relier ces compteurs au bon périphérique. Si les ralentissements s’accompagnent d’erreurs, contrôlez aussi les messages du noyau :

journalctl -k -b -p warning..alert
systemctl --failed

Retrouver le processus avant de redémarrer un service

vmstat indique la nature probable du blocage, pas le nom du processus. Triez ensuite les tâches selon la ressource suspecte :

ps -eo pid,user,stat,ni,pcpu,pmem,comm --sort=-pcpu | head
ps -eo pid,user,stat,ni,pcpu,pmem,comm --sort=-pmem | head
htop

Dans STAT, un état D correspond généralement à un sommeil non interruptible. Il peut expliquer une colonne b élevée, mais ne tuez pas le PID immédiatement. Identifiez d’abord son service, ses fichiers ouverts et ses logs :

ps -fp PID
systemctl status service-concerne --no-pager
journalctl -u service-concerne -n 100 --no-pager

Une base de données peut consommer beaucoup de RAM sans fuite, et un processus en état D peut attendre un disque ou un stockage réseau. Le redémarrage masque parfois le symptôme sans corriger la panne. Vérifiez la durée, la charge métier et les erreurs avant toute action.

Décider à partir des compteurs qui se recoupent

Le diagnostic devient exploitable quand plusieurs colonnes racontent la même chose :

• CPU saturé : r reste haut par rapport à nproc, avec us ou sy élevé et peu de id ;
• pression mémoire : available reste bas, si ou so reviennent sur plusieurs échantillons et la latence augmente ;
• attente disque : b et wa montent, puis iostat confirme un périphérique lent ;
• contention de virtualisation : st reste visible sur une VM malgré une charge interne modérée.

Pour rechercher un passage de l’OOM killer, utilisez les logs du noyau :

journalctl -k -b | grep -Ei 'out of memory|oom-killer|killed process'

La page de manuel de vmstat décrit chaque champ. Celle de iostat détaille les métriques de stockage. Conservez vos relevés avant et pendant le ralentissement : sans comparaison dans le temps, même un compteur élevé reste difficile à interpréter.

sudo apt update && sudo apt upgrade