infra / linux-bash
Monitoring et performance (top/htop, iostat, vmstat, df/du)
Explication
Ce que vous allez apprendre
- Diagnostiquer un serveur lent en suivant un ordre méthodique (CPU, mémoire, disque, puis réseau) au lieu d'agir au hasard
- Interpréter correctement le load average en le rapportant au nombre de coeurs (
nproc) - Distinguer une photo instantanée (
top) d'une tendance mesurée dans le temps (vmstat,sar) - Repérer un goulot d'étranglement disque grâce au
%utildeiostat -xz - Identifier deux limites logicielles souvent oubliées en production :
ulimit -netvm.swappiness
Dans quel contexte ?
Tu es d'astreinte et un client signale que l'API met 8 secondes à répondre au lieu de 200 ms. Tu te connectes en SSH sur prod-api-02 : avant de redémarrer quoi que ce soit au hasard, il faut savoir dans quel ordre regarder (CPU ? mémoire ? disque ?) pour identifier la vraie cause en quelques minutes.
D'abord, la bonne réflexion à avoir face à un serveur lent
Face à un serveur qui répond mal, la tentation est d'agir tout de suite. La bonne démarche est inverse : observer précisément où se situe le ralentissement (CPU, mémoire, disque, réseau) avant de toucher à quoi que ce soit.
Commençons par l'indicateur le plus consulté : le load average
uptime affiche trois nombres, la charge moyenne sur 1, 5 et 15 minutes. Mais ce chiffre seul ne dit rien : un load de 4.0 est normal sur une machine à 4 coeurs (nproc donne ce nombre), tandis que le même 4.0 sur une machine à 1 coeur signale une vraie saturation.
Réflexe à adopter
Ne jamais lire un load average sans vérifier nproc juste à côté : le même chiffre peut vouloir dire "tout va bien" ou "système saturé" selon le nombre de coeurs disponibles.
Une fois le load average interprété, il faut aller plus loin sur le CPU et la mémoire
top ou htop donnent une photo à l'instant T, utile pour un diagnostic rapide. free -h montre la mémoire utilisée et le cache, tandis que vmstat 1 5 prend 5 échantillons espacés d'une seconde pour voir une tendance qu'une seule capture ne montrerait pas.
| Outil | Ressource observée | Photo ou tendance |
|---|---|---|
top / htop | CPU, mémoire | Photo instantanée |
free -h | Mémoire, cache | Photo instantanée |
vmstat 1 5 | CPU, mémoire, swap | Tendance (plusieurs échantillons) |
iostat -xz 1 | Disque (%util) | Tendance |
sar -u / -r / -q | CPU / mémoire / charge, historisés | Tendance longue durée |
Il reste une ressource souvent négligée : le disque
iostat -xz 1 affiche le %util de chaque disque chaque seconde : proche de 100%, il révèle un goulot d'étranglement I/O que le CPU ne montrerait jamais. du -sh /var/log/* | sort -rh retrouve rapidement quel dossier fait gonfler l'espace utilisé.
Maintenant, un piège que peu de gens connaissent : les limites logicielles
Un service qui plante sous forte charge n'a pas forcément un problème matériel : ulimit -n limite le nombre de fichiers ouverts simultanément par une session, et une base de données qui dépasse cette limite plantera même avec du CPU et de la RAM disponibles. sysctl vm.swappiness règle, lui, la tendance du noyau à utiliser le swap plutôt que la RAM.
Le piège à connaître
Confondre "photo à l'instant T" et "tendance" fait rater des pics de charge intermittents : un top lancé une fois par heure ne verra jamais un pic de 30 secondes. Maintenant que tu sais diagnostiquer un serveur, la prochaine leçon montre comment écrire des scripts fiables pour la production, qui anticipent justement ce genre de problème.
Commandes & code
Monitoring et performance
# --- CPU et mémoire en temps réel ---
top # vue classique
htop # vue moderne, interactive, plus lisible (paquet à installer)
# Dans htop : F6 trie par colonne, F9 tue un process, t affiche l'arbre
free -h # mémoire libre/utilisée/cache, format lisible
free -h -s 2 # rafraîchit toutes les 2 secondes
uptime # charge moyenne (load average) sur 1/5/15 minutes
nproc # nombre de coeurs CPU disponibles
mpstat -P ALL 1 # détail d'utilisation par coeur, chaque seconde
# --- Interprétation du load average ---
# Load average de 4.0 sur une machine à 4 coeurs = 100% de charge (normal)
# Load average de 8.0 sur une machine à 4 coeurs = système saturé, files d'attente CPU
# --- I/O disque ---
iostat -xz 1 # utilisation détaillée des disques, chaque seconde (%util = clé)
iotop # équivalent de top mais pour l'I/O disque, par processus
df -h # espace disque par système de fichiers
df -i # inodes utilisés (un disque peut être "plein" en inodes)
du -sh /var/log/* # taille par sous-dossier, pour trouver ce qui gonfle
ncdu /var # explorateur interactif de l'usage disque
# --- Mémoire virtuelle et swap ---
vmstat 1 5 # 5 échantillons, 1 par seconde : r(unnable), b(locked), swap, io, cpu
vmstat -s # statistiques cumulées depuis le boot
swapon --show # swap actif et son taux d'utilisation
# --- Réseau ---
ss -s # résumé des connexions
sar -n DEV 1 5 # débit réseau par interface (paquet sysstat)
iftop # bande passante en temps réel par connexion (nécessite root)
nload # graphique simple entrée/sortie par interface
# --- Processus les plus gourmands ---
ps aux --sort=-%cpu | head -10 # top 10 CPU
ps aux --sort=-%mem | head -10 # top 10 mémoire
# --- Historique de performance avec sysstat ---
sudo apt install sysstat
sar -u 1 5 # CPU
sar -r 1 5 # mémoire
sar -q 1 5 # load average
sar -u -f /var/log/sysstat/sa03 # relire les données collectées automatiquement du jour 03
# --- Limites système (souvent la vraie cause d'un problème en prod) ---
ulimit -a # limites de la session courante (fichiers ouverts, processus...)
ulimit -n # nombre max de descripteurs de fichiers ouverts
cat /proc/sys/fs/file-max # limite système globale
sysctl vm.swappiness # tendance du noyau à utiliser le swap (0-100)
sudo sysctl -w vm.swappiness=10 # réduit l'usage du swap au profit du cache (serveurs de BDD)Résumé
top/htoppour l'instantané,vmstat/iostat/sarpour observer une tendance dans le temps.- Un
%utildisque proche de 100% dansiostat -xzrévèle souvent un goulot d'étranglement I/O, pas CPU. ulimit/sysctl(fichiers ouverts, swappiness) sont des causes fréquentes de problèmes de perf en prod, souvent oubliées.
Exercices pratiques
Mission : trouver pourquoi l'API répond en 8 secondes
Objectif : Diagnostiquer méthodiquement un serveur lent en distinguant photo instantanée et tendance.
Contexte
Tu es d'astreinte : un client signale que l'API met 8 secondes à répondre au lieu de 200 ms. Tu te connectes en SSH sur prod-api-02. Avant de redémarrer quoi que ce soit, tu dois identifier méthodiquement où se situe le ralentissement.