Linux en production : 15 commandes pour diagnostiquer un serveur lent ou saturé

Le site met dix secondes à répondre, l’application métier se fige, les utilisateurs appellent. Sur un serveur Linux, la cause se trouve presque toujours dans l’une des quatre ressources : processeur, mémoire, disque ou réseau. Encore faut-il savoir laquelle, et vite. Voici 15 commandes, à lancer dans l’ordre, qui permettent de poser un diagnostic en quelques minutes, sans rien installer de complexe.

L’essentiel en 30 secondes

• Méthode : pour chaque ressource, regarder l’utilisation, la saturation (file d’attente) et les erreurs.
• Les 60 premières secondes : uptime, dmesg, vmstat, iostat, free, df.
• La plupart des outils viennent des paquets procps et sysstat, présents ou installables sur toutes les distributions.
• Notez l’heure et les valeurs : elles serviront à comparer après correction.

Vue d’ensemble

1. uptime : la charge moyenne

uptime

Les trois chiffres de « load average » indiquent la charge sur 1, 5 et 15 minutes. Comparez-les au nombre de cœurs (nproc) : une charge de 12 sur 4 cœurs signale une saturation. Une charge qui monte (1 min supérieure à 15 min) indique un problème en cours.

2. dmesg : les erreurs du noyau

sudo dmesg -T | tail -30

On y repère les processus tués par manque de mémoire (« Out of memory: Killed process »), les erreurs disque et les problèmes de carte réseau.

3. journalctl : les erreurs des services

journalctl -p err -b --since "1 hour ago"
systemctl --failed

Processeur

4. vmstat : l’état général seconde par seconde

vmstat 1 5

Colonnes clés : r (processus en attente de CPU, à comparer au nombre de cœurs), us/sy (temps utilisateur et système), wa (attente des entrées-sorties, souvent le disque), si/so (échanges avec le swap, signe de manque de mémoire).

5. mpstat : répartition par cœur

mpstat -P ALL 1 3

Un seul cœur à 100 % alors que les autres sont au repos révèle un processus mono-thread qui plafonne.

6. top ou htop : qui consomme

top -o %CPU

Dans top, la touche 1 affiche chaque cœur et M trie par mémoire. htop offre la même chose de façon plus lisible.

7. pidstat : consommation par processus dans le temps

pidstat -u -r -d 1 5

Processeur, mémoire et disque par processus : idéal pour attraper un pic intermittent.

Mémoire

8. free : mémoire et swap

free -h

Regardez la colonne available, pas « free » : Linux utilise la mémoire libre comme cache disque, c’est normal. Un swap très utilisé et en mouvement (colonnes si/so de vmstat) indique un vrai manque de mémoire.

9. ps : les processus les plus gourmands

ps aux --sort=-%mem | head -10

Disque

10. iostat : la saturation des disques

iostat -xz 1 3

Colonnes clés : %util proche de 100 % (disque saturé), r_await/w_await (latence en millisecondes ; au-delà de quelques dizaines sur un SSD, il y a un problème), aqu-sz (file d’attente).

11. df : l’espace et les inodes

df -h
df -i

Un disque plein à 100 % bloque bases de données et journaux. Le manque d’inodes (trop de petits fichiers, sessions PHP par exemple) produit le même effet alors qu’il reste de l’espace.

12. du et lsof : qui remplit le disque

sudo du -xh --max-depth=1 /var | sort -h | tail
sudo lsof +L1

lsof +L1 révèle les fichiers supprimés mais encore ouverts par un processus : l’espace n’est libéré qu’au redémarrage du service concerné. Cas classique avec un gros journal effacé à la main.

Réseau

13. ss : les connexions

ss -s
ss -tunap | head -30

Des milliers de connexions en TIME-WAIT ou SYN-RECV peuvent signaler une surcharge ou une attaque. Pour savoir qui se connecte le plus : ss -tn state established | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n | tail.

14. sar : le débit et les erreurs des interfaces

sar -n DEV 1 3
sar -n EDEV 1 3

Une interface au maximum de son débit, ou des erreurs et pertes de paquets, orientent vers le réseau plutôt que vers le serveur.

15. sar en historique : que s’est-il passé cette nuit ?

sar -u -f /var/log/sysstat/sa$(date +%d -d yesterday)

Si sysstat collecte en continu, vous pouvez revoir la charge, la mémoire et le disque à l’heure exacte du problème signalé. Le chemin varie selon la distribution (/var/log/sa/ sur les dérivés de Red Hat).

Interpréter : le tableau de synthèse

Une consommation CPU anormale et persistante, la nuit, sans raison métier, doit aussi faire penser à un mineur de cryptomonnaie installé par un attaquant : vérifiez les processus inconnus et les tâches planifiées.

Prévenir plutôt que guérir

Ces commandes servent au diagnostic. Pour être alerté avant que les utilisateurs appellent, installez une supervision légère comme Beszel ou plus complète comme NetXMS, avec des seuils sur le disque, la mémoire et la charge.

Questions fréquentes

Que faire si ces commandes ne sont pas installées ?

Installez le paquet sysstat (iostat, mpstat, pidstat, sar) et éventuellement htop. Activez la collecte de sysstat pour disposer d’un historique.

La charge moyenne est élevée mais le CPU est au repos : pourquoi ?

Sous Linux, la charge inclut les processus bloqués en attente du disque ou du réseau (état D). Regardez %wa dans vmstat et iostat.

Faut-il redémarrer le serveur ?

En dernier recours. Un redémarrage efface les indices et le problème reviendra. Collectez d’abord les informations, puis redémarrez seulement le service en cause si nécessaire.

Ces commandes fonctionnent-elles dans un conteneur ?

Partiellement : un conteneur voit souvent les ressources de l’hôte. Utilisez docker stats et les métriques des cgroups pour connaître la consommation réelle de chaque conteneur.

Sources

• Brendan Gregg, The USE Method.
• Brendan Gregg (Netflix), « Linux Performance Analysis in 60 seconds ».
• Projet sysstat.

Besoin d’un accompagnement ?

MPCÂBLE Solutions Informatiques (MPCSI) accompagne particuliers, entreprises, associations et collectivités depuis Gaudiès, en Ariège : sur site en Occitanie, principalement dans un rayon de 40 km (Pamiers, Foix, Mirepoix, Saverdun, Castelnaudary), et à distance partout en France. Pour un diagnostic ou une supervision continue, voir notre infogérance. Demandez un devis gratuit ou appelez le 05 32 42 99 98.