Performance Linux : troubleshooting méthodique en production

Lecture : 10 minutes · Niveau : intermédiaire-avancé · Mise à jour : avril 2026

« Le serveur est lent ». Cette phrase recouvre des dizaines de causes possibles : CPU saturé, RAM épuisée, disque I/O saturé, réseau qui rame, base de données mal indexée, processus zombie, swap qui thrash. Sans méthode, on perd des heures à chasser le mauvais coupable. Ce guide pose une démarche systématique.

Voir aussi → Linux administration avancée pour PME : guide pratique.

Sommaire

1. La méthode USE : Utilisation, Saturation, Erreurs
2. Premier coup d’œil : top, htop, uptime
3. Diagnostic CPU
4. Diagnostic mémoire et swap
5. Diagnostic disque I/O
6. Diagnostic réseau
7. Outils avancés : perf, bpftrace
8. Plan d’action quand tout est lent
9. FAQ

1. La méthode USE : Utilisation, Saturation, Erreurs

Brendan Gregg, ingénieur performance reconnu (ex-Netflix, Intel), propose la méthode USE (brendangregg.com/usemethod.html) : pour chaque ressource, mesurer trois choses :

• Utilisation : pourcentage de temps occupé
• Saturation : files d’attente, ressource qui doit attendre
• Erreurs : compteurs d’erreur

Appliqué à un serveur, on inspecte chaque ressource (CPU, mémoire, disque, réseau) sous ces trois angles. Cela force une investigation complète et évite de se fixer trop tôt sur une hypothèse.

2. Premier coup d’œil : top, htop, uptime

uptime — la météo en une ligne

uptime
# 14:23:01 up 12 days,  3:42,  2 users,  load average: 1.42, 1.85, 2.13

Les trois nombres représentent la charge moyenne sur 1, 5 et 15 minutes. Sur une machine à N cœurs :

• Load < N : machine confortable
• Load ≈ N : machine pleine, pas de marge
• Load > N : tâches en attente, ressource saturée

Tendance : si load 1 min > load 15 min → la charge augmente. Si load 1 min < load 15 min → ça se calme.

htop — vision détaillée

sudo apt install htop
htop

À regarder en priorité :
– CPU bars : 100% sur tous les cœurs = CPU saturé
– Mem : si la barre est presque pleine ET swap utilisé → pression mémoire
– Load average (en haut à droite) : cohérent avec uptime
– Top processus par CPU (P) ou par mémoire (M)

3. Diagnostic CPU

Identifier qui consomme

# Top 10 processus par CPU
ps aux --sort=-%cpu | head -11

# En continu
htop  # touche P pour trier par CPU

# Statistiques globales par cœur
mpstat -P ALL 2 5

Comprendre la décomposition

Dans top ou mpstat, le CPU est décomposé :

Patterns courants :
– %us haut + processus identifié → optimiser le code applicatif
– %sy haut → trop de syscalls (souvent fork/exec excessif, fuite de descripteurs)
– %wa haut → ce n’est pas un problème CPU mais I/O. Voir section disque
– %st haut → la VM voisine consomme tout. Plainte au cloud provider ou changement de plan

Identifier les threads (pas seulement les processus)

top -H -p $(pgrep -d',' nom_processus)
# -H montre les threads

Utile pour les serveurs applicatifs multi-thread (Java, Python avec asyncio, Node.js avec workers).

4. Diagnostic mémoire et swap

Vue rapide

free -h
#                total        used        free      shared  buff/cache   available
# Mem:           7.7Gi       5.2Gi       312Mi        45Mi       2.2Gi       2.1Gi
# Swap:          2.0Gi       1.5Gi       512Mi

Le bon indicateur, c’est available, pas free. Linux utilise la RAM libre comme cache disque (buff/cache) — c’est normal et bénéfique. available est ce qu’une nouvelle application pourrait obtenir sans swap.

Signaux d’alerte :
– available < 10% de la RAM totale
– Swap utilisé ET si/so > 0 dans vmstat (le système swap activement)

vmstat — voir la pression mémoire en direct

vmstat 2 10
# procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
#  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
#  2  0 1572864 312456  ... ...      45    87  3245   876 4521 8932 25  8 50 17  0

si (swap in) et so (swap out) doivent être proches de 0 sur une machine saine. Des chiffres soutenus = swap thrashing = très mauvaise performance.

Top consommateurs

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

# Détail par processus
sudo pmap -x <PID> | tail -1

OOM Killer

Si un processus disparaît mystérieusement, vérifier l’OOM (Out-Of-Memory) Killer :

sudo dmesg -T | grep -i "killed process"
sudo journalctl -k | grep -i oom

Le kernel tue le plus gros consommateur quand la RAM est épuisée. Solutions : ajouter de la RAM, mettre une limite mémoire au service via systemd (MemoryMax=2G), optimiser le code.

5. Diagnostic disque I/O

Espace disque

df -h            # espace par partition
df -i            # inodes (souvent oublié — peut être saturé même avec espace libre)

# Top dossiers volumineux dans /
sudo du -sh /var/* /opt/* 2>/dev/null | sort -hr | head -10

df -i est crucial : avec énormément de petits fichiers, on peut épuiser les inodes alors qu’il reste de l’espace octet.

I/O en temps réel

sudo apt install iotop sysstat

# Top processus par I/O
sudo iotop -aoP

# Statistiques disque par seconde
iostat -xz 2 5

Dans iostat -xz :

Trouver le coupable

# Quels processus écrivent quoi ?
sudo iotop -aoP

# Quels fichiers sont les plus accédés ?
sudo lsof | awk '{print $9}' | sort | uniq -c | sort -rn | head -20

6. Diagnostic réseau

Bande passante

sudo apt install iftop nethogs

# Bande passante par connexion
sudo iftop -i eth0

# Bande passante par processus
sudo nethogs eth0

Connexions et états TCP

# Stats TCP
ss -s

# Connexions par état
ss -tan | awk 'NR>1 {print $1}' | sort | uniq -c

# Beaucoup de TIME_WAIT ?
ss -tan state time-wait | wc -l

Beaucoup de TIME_WAIT est normal sur un serveur web actif. Beaucoup de CLOSE_WAIT indique souvent une application qui ne ferme pas ses sockets correctement (bug applicatif).

Latence

# Latence vers une cible
ping -c 10 8.8.8.8

# Latence par segment
mtr 8.8.8.8

# Test bande passante (entre deux serveurs)
# serveur : iperf3 -s
# client  : iperf3 -c <ip-serveur>

DNS lent ?

# Mesurer la latence DNS
time dig +short google.com

# Si lent : tester un autre resolver
dig @1.1.1.1 google.com
dig @8.8.8.8 google.com

Un DNS lent ralentit tout (chaque requête HTTP commence par une résolution DNS si pas en cache).

7. Outils avancés : perf, bpftrace

Pour les cas qui ne se révèlent pas avec les outils précédents :

perf — profiler système

sudo apt install linux-tools-common linux-tools-$(uname -r)

# Top des fonctions consommatrices (10 secondes)
sudo perf top

# Profil d'un processus spécifique
sudo perf record -p <PID> -g -- sleep 30
sudo perf report

perf montre où le temps CPU est passé, dans le code lui-même, jusqu’à la fonction précise. Indispensable pour optimiser un service applicatif.

bpftrace — observabilité dynamique

sudo apt install bpftrace

# Toutes les ouvertures de fichiers
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat { printf("%s %s\n", comm, str(args->filename)); }'

# Latence des syscalls read
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_read { @start[tid] = nsecs; }
                  tracepoint:syscalls:sys_exit_read /@start[tid]/ { @us = hist((nsecs - @start[tid])/1000); delete(@start[tid]); }'

bpftrace permet d’instrumenter le système en direct sans redémarrer ni modifier le code. Très puissant mais demande de la pratique. Documentation : github.com/iovisor/bpftrace.

8. Plan d’action quand tout est lent

Routine en 5 minutes :

# 1. Vue globale
uptime
free -h
df -h

# 2. Top consommateurs
htop  # ou : ps aux --sort=-%cpu | head ; ps aux --sort=-%mem | head

# 3. I/O ?
sudo iotop -aoP -n 5 -d 1

# 4. Erreurs récentes
sudo journalctl -p err --since "1 hour ago" | tail -50

# 5. Réseau saturé ?
ss -s
sudo iftop -i eth0  # 10s puis Ctrl+C

Cette séquence isole 90% des cas. Si rien d’évident :

• Vérifier les services systemd en boucle de redémarrage : systemctl --failed
• Vérifier la cohérence du système de fichiers : dmesg | grep -i error
• Identifier les requêtes lentes côté DB (logs MySQL/Postgres)
• Profiler l’application avec perf si CPU-bound applicatif

Voir aussi → systemd services en production : tutoriel pratique pour superviser les redémarrages en boucle.

9. FAQ

Mon load average est élevé mais les CPUs sont à 30%, pourquoi ?

Le load Linux compte les processus en état D (uninterruptible sleep, généralement attente I/O) en plus des processus runnable. Un load haut avec CPU bas = processus bloqués sur I/O disque ou réseau. Vérifier iostat -xz et iotop.

Dois-je désactiver le swap sur un serveur ?

Non par défaut. Un peu de swap absorbe les pics et évite l’OOM Killer sur des allocations rares. Le problème est le swap actif (swap thrashing). Mieux : garder un peu de swap (1-2 Go) et surveiller vmstat. Désactiver totalement le swap est utile uniquement pour des workloads spécifiques (Kubernetes recommande swap off, mais c’est un cas particulier).

iotop montre 100% I/O mais le disque a l’air vide niveau usage. Comment ?

Beaucoup de petits I/O sur SSD peuvent saturer l’IOPS sans saturer le débit. Regarder iostat -xz : si r/s + w/s est élevé mais rkB/s et wkB/s faibles, c’est de la fragmentation d’I/O. Souvent : journaux verbeux, base de données en sync trop fréquent, ou logs applicatifs en mode synchrone.

Comment mesurer la latence vraie d’une requête HTTP de bout en bout ?

curl avec format détaillé : curl -w "@curl-format.txt" -o /dev/null -s https://example.com où curl-format.txt détaille DNS, connect, TLS, TTFB, total. Format complet sur curl.se/docs/manpage.html. Pour mesures en production : un outil comme vegeta ou k6 avec des dashboards.

Quel est le coût performance du sandboxing systemd ?

Négligeable pour 95% des services (quelques pourcents au démarrage, indétectable en runtime). Les directives comme SystemCallFilter ajoutent un petit overhead par syscall, sans impact mesurable sur des charges normales. Le rapport bénéfice sécurité / coût performance est très favorable au durcissement.

Combien de temps une investigation perf doit prendre avant d’escalader ?

Si en 30-60 minutes la cause n’est pas identifiée, élargir : impliquer un collègue (ou prestataire), installer des outils complémentaires (Grafana + Prometheus pour historique), considérer que le problème vient d’ailleurs (changement applicatif récent, dépendance externe). Beaucoup de problèmes « Linux » sont en réalité des bugs applicatifs.

Articles liés (cluster Linux administration)

• 👉 Linux administration avancée pour PME : guide pratique 2026 (pillar)
• 👉 systemd services en production : tutoriel pratique
• 👉 Linux sécurité et hardening en production

Article mis à jour le 25 avril 2026. Pour signaler une erreur ou suggérer une amélioration, écrivez-nous.