Diagnostiquer les problèmes de performance Linux

Votre serveur Linux est lent et vous ne savez pas par où commencer ? Ce guide vous apprend à diagnostiquer rapidement les problèmes de performance en utilisant la méthode USE (Utilization, Saturation, Errors). En 10 minutes, vous saurez identifier si le problème vient du CPU, de la mémoire, du disque ou du réseau — et quelles commandes utiliser pour le confirmer.

Vous apprendrez à :

• Comprendre les 4 types de contention qui ralentissent un serveur
• Appliquer la méthode USE de manière systématique
• Interpréter les métriques avec les bonnes commandes
• Corriger les problèmes les plus courants

Prérequis

Ce guide suppose que vous avez :

• Un accès SSH à un serveur Linux (Ubuntu, Debian, Rocky, etc.)
• Les droits sudo pour installer des outils si nécessaire
• Une connaissance basique du terminal (savoir taper une commande)

Si vous débutez complètement avec Linux, consultez d’abord notre guide sur les commandes de base Linux.

Qu’est-ce qu’un problème de performance ?

Imaginez un serveur comme une cuisine de restaurant. Quand tout va bien, les plats sortent régulièrement. Mais si le chef est débordé (CPU), s’il manque de plans de travail (mémoire), si le frigo est trop lent à ouvrir (disque), ou si les serveurs se bousculent dans le couloir (réseau), tout ralentit.

En informatique, on appelle ça une contention : une ressource est sollicitée au-delà de ses capacités, créant une file d’attente.

Pourquoi un serveur devient-il lent ?

Un serveur exécute des processus (des programmes en cours d’exécution). Chaque processus a besoin de ressources pour fonctionner :

• Du temps CPU pour effectuer des calculs
• De la mémoire RAM pour stocker ses données temporaires
• Des accès disque pour lire/écrire des fichiers
• De la bande passante réseau pour communiquer

Quand trop de processus demandent la même ressource en même temps, ils doivent faire la queue. C’est cette attente qui crée la lenteur.

Analogie de la file d'attente

Pensez à une caisse de supermarché :

• 1 client, 1 caisse → Service instantané
• 5 clients, 1 caisse → File d’attente, chacun attend son tour
• 20 clients, 1 caisse → Attente interminable

C’est exactement ce qui se passe sur un serveur surchargé. La solution ? Soit réduire le nombre de clients (processus), soit ouvrir plus de caisses (ajouter des ressources).

Les 4 ressources à surveiller

Sur un serveur Linux, les problèmes de performance viennent toujours d’une de ces 4 ressources :

• CPU — le processeur qui exécute les calculs
• Mémoire — la RAM qui stocke les données temporaires
• Disque — le stockage pour les fichiers et bases de données
• Réseau — la bande passante pour communiquer

Les 4 types de contention

Avant de plonger dans les commandes, comprenons ce qui peut mal tourner sur chaque ressource.

CPU (processeur)

Le CPU (Central Processing Unit) est le “cerveau” de l’ordinateur. Il exécute toutes les instructions des programmes. Quand le CPU est saturé, tout devient lent car les processus doivent attendre leur tour pour être exécutés.

Signes révélateurs : applications qui “rament”, temps de réponse élevé, ventilateurs qui tournent fort.

Mémoire (RAM)

La RAM (Random Access Memory) est la mémoire à court terme du serveur. Les programmes y stockent les données qu’ils utilisent activement. Quand elle est pleine, Linux utilise le swap (espace disque utilisé comme mémoire de secours), ce qui est 100 à 1000 fois plus lent.

Signes révélateurs : swap utilisé, processus tués automatiquement (OOM-Killer), lenteur soudaine.

Disque (stockage)

Le disque stocke les données de façon permanente (fichiers, bases de données, logs). Les opérations disque sont naturellement plus lentes que la RAM. Quand le disque est saturé, même les opérations simples prennent du temps.

Signes révélateurs : fichiers longs à ouvrir, bases de données lentes, %iowait élevé dans les métriques.

Réseau (bande passante)

Le réseau permet au serveur de communiquer avec l’extérieur (utilisateurs, autres serveurs, APIs). Quand la bande passante est saturée ou mal configurée, les connexions échouent ou sont très lentes.

Signes révélateurs : timeouts, connexions refusées, téléchargements lents.

Contention	Symptômes typiques	Causes fréquentes
CPU	Processus lents, latence élevée	Trop de processus, calculs intensifs
Mémoire	Swap actif, OOM-Killer	Applications gourmandes, fuites mémoire
Disque	Lecture/écriture lente, %iowait élevé	Base de données non optimisée, logs excessifs
Réseau	Connexions refusées, timeouts	Bande passante saturée, attaques DDoS

Glissez pour voir

La méthode USE : une approche systématique

La méthode USE (Utilization, Saturation, Errors), créée par Brendan Gregg, expert performance chez Netflix, propose d’analyser chaque ressource selon 3 critères :

Critère	Question à poser	Ce que ça révèle
U - Utilization	Quel % de la ressource est utilisé ?	Si proche de 100%, elle est saturée
S - Saturation	Y a-t-il une file d’attente ?	Des processus attendent la ressource
E - Errors	Y a-t-il des erreurs ?	Problèmes matériels ou de configuration

Glissez pour voir

Pourquoi cette méthode fonctionne

La méthode USE évite les analyses incomplètes. Sans elle, on peut passer des heures sur le CPU alors que le problème vient du disque. En analysant systématiquement chaque ressource, vous identifiez le vrai goulot d’étranglement.

Comprendre le load average

Avant d’analyser chaque ressource, parlons du load average — la métrique la plus connue mais aussi la plus mal comprise.

Qu’est-ce que le load average ?

Le load average (charge moyenne) est un nombre qui représente combien de travail le système doit effectuer. Plus précisément, c’est le nombre moyen de processus qui :

1. S’exécutent actuellement sur un CPU
2. Attendent un CPU disponible
3. Attendent une opération disque (I/O)

Analogie du péage autoroutier

Imaginez un péage avec plusieurs guichets (les cœurs CPU) :

• Load = 0 : Aucune voiture, les guichets sont vides
• Load = 1 : Exactement une voiture par guichet, flux parfait
• Load = 2 : Deux voitures par guichet, une file d’attente se forme
• Load = 10 : Embouteillage massif, longue attente

Le load average vous dit combien de “voitures” (processus) sont en train de passer ou d’attendre.

Comment voir le load average ?

uptime

11:05:07 up 15 days, 5:57, 1 user, load average: 2.70, 2.40, 2.07

Le load average montre le nombre de processus qui sont soit en exécution, soit en attente du CPU, sur 3 périodes :

• 1ère valeur (2.70) : dernière minute (charge actuelle)
• 2ème valeur (2.40) : 5 dernières minutes (tendance court terme)
• 3ème valeur (2.07) : 15 dernières minutes (tendance long terme)

Comment lire cette tendance ?

• Si la 1ère valeur > 3ème valeur → La charge augmente (pic en cours)
• Si la 1ère valeur < 3ème valeur → La charge diminue (retour à la normale)
• Si les 3 valeurs sont proches → Charge stable

Comment interpréter ces chiffres ?

La règle d’or : divisez par le nombre de cœurs CPU.

Pourquoi ? Parce qu’un serveur avec 4 cœurs peut exécuter 4 processus en parallèle. Un load de 4 sur un serveur 4 cœurs signifie que chaque cœur travaille à 100% — c’est la limite avant que des processus ne commencent à attendre.

nproc
4

Cette commande affiche le nombre de cœurs CPU disponibles.

Sur un serveur 4 cœurs :

Load average	Calcul	Interprétation
2.0	2.0 / 4 = 0.5	✅ 50% d’utilisation, tout va bien
4.0	4.0 / 4 = 1.0	⚠️ 100% utilisé, à surveiller
8.0	8.0 / 4 = 2.0	🔴 Surcharge, des processus attendent

Glissez pour voir

Exemple concret

Si nproc retourne 8 et que votre load average est 12 :

• Calcul : 12 / 8 = 1.5
• Interprétation : 50% de processus en plus de ce que le CPU peut gérer
• Action : investiguer immédiatement

Le load average ne dit pas tout

Un load average élevé indique une contention, mais ne dit pas laquelle. Un disque lent peut gonfler le load average car les processus attendent les IO. Utilisez les commandes suivantes pour identifier la vraie cause.

Diagnostic CPU

Le CPU est souvent le premier suspect quand un serveur est lent. Voyons comment vérifier s’il est réellement en cause.

Étape 1 : Vérifier l’utilisation globale

La commande mpstat (Multi-Processor Statistics) montre comment le CPU répartit son temps entre différentes activités :

mpstat -P ALL 1 3

Décortiquons cette commande :

• mpstat : affiche les statistiques CPU
• -P ALL : pour tous les cœurs (pas seulement la moyenne)
• 1 : rafraîchir toutes les 1 seconde
• 3 : pendant 3 itérations

CPU    %usr   %sys  %iowait  %idle
all    75.2   10.3     8.5     6.0
  0    80.1   10.5     5.2     4.2
  1    70.3   10.1    11.8     7.8

Que signifie chaque colonne ?

Le CPU divise son temps en plusieurs catégories. Imaginez une journée de travail :

Métrique	Analogie	Signification technique	Seuil d’alerte
%usr	Travail productif	Temps passé sur vos applications (MySQL, Nginx, etc.)	> 80% constant
%sys	Réunions internes	Temps passé sur le noyau Linux (gestion mémoire, réseau)	> 20%
%iowait	Attente du courrier	CPU inactif car il attend le disque	> 10%
%idle	Pause café	CPU qui ne fait rien, disponible	< 10% = surcharge

Glissez pour voir

Astuce de lecture

La somme de toutes les colonnes fait toujours 100%. Si %idle est bas, le CPU travaille beaucoup. La question est : sur quoi ?

• %usr élevé = vos applications travaillent dur
• %iowait élevé = le CPU attend le disque (ce n’est pas un problème CPU !)

Décryptage rapide

• %idle faible + %usr élevé → Vos applications consomment tout le CPU
• %idle faible + %iowait élevé → Le CPU attend le disque (problème IO)
• %sys élevé → Le noyau travaille beaucoup (réseau, processus)

Étape 2 : Identifier les processus gourmands

top -o %CPU

Appuyez sur 1 pour voir chaque cœur, q pour quitter.

Vérification : Le processus en haut consomme-t-il plus de 90% ?

Étape 3 : Vérifier la saturation

vmstat 1 5

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 7  0      0 102400  51200 512000    0    0     5    10  200  400 75 10  5 10  0

La colonne r est clé : elle montre les processus en attente du CPU.

• r ≤ nombre de cœurs → OK
• r > nombre de cœurs → Saturation CPU

Corrections possibles

1. Identifier le processus fautif avec top et vérifier s’il est normal qu’il consomme autant.

2. Réduire la priorité d’un processus non critique :

   renice +10 -p <PID>

3. Limiter les ressources avec cgroups ou taskset :

   taskset -c 0,1 mon_processus

4. Optimiser l’application : profiler avec perf top pour trouver les fonctions gourmandes.

Diagnostic mémoire

La mémoire RAM est cruciale pour les performances. Contrairement au CPU qui peut “faire la queue”, quand la RAM est pleine, Linux doit prendre des mesures drastiques.

Comment Linux gère la mémoire

Avant de regarder les commandes, comprenons comment Linux utilise la RAM :

1. Mémoire applicative : utilisée par vos programmes (MySQL, Nginx, etc.)
2. Buffer/Cache : Linux utilise la RAM “libre” pour accélérer les accès disque
3. Swap : espace disque utilisé comme “RAM de secours” (très lent)

Pourquoi Linux utilise toute la RAM ?

Si vous voyez 95% de RAM utilisée, ne paniquez pas immédiatement. Linux est intelligent : plutôt que de laisser la RAM vide, il l’utilise comme cache pour accélérer les lectures disque.

Ce cache est libéré automatiquement quand une application a besoin de mémoire. C’est pourquoi la colonne free peut être très basse sans que ce soit un problème.

Étape 1 : Vérifier l’utilisation

free -h

L’option -h affiche les valeurs en format lisible (Gi, Mi) au lieu d’octets.

              total        used        free      shared  buff/cache   available
Mem:           16Gi        12Gi       1.5Gi       145Mi       2.5Gi       3.2Gi
Swap:         2.0Gi       512Mi       1.5Gi

Décryptage ligne par ligne :

Colonne	Signification	Dans notre exemple
total	RAM totale installée	16 Go
used	RAM utilisée (apps + cache)	12 Go
free	RAM complètement libre	1.5 Go
buff/cache	RAM utilisée pour le cache disque	2.5 Go
available	RAM réellement disponible pour de nouvelles apps	3.2 Go

Glissez pour voir

Ce qui compte vraiment :

• available (pas free !) : mémoire réellement disponible pour les applications
• Swap used : si > 0, la mémoire RAM est insuffisante

Ne regardez pas 'free' !

Linux utilise la RAM libre comme cache disque (buff/cache). C’est normal et optimise les performances. La colonne available montre la vraie mémoire disponible.

Dans notre exemple : available = free + buff/cache récupérable = 3.2 Gi

Étape 2 : Vérifier la saturation (swap)

vmstat 1 5

Regardez les colonnes si (swap-in) et so (swap-out) :

---swap--
  si   so
  10   35

• si/so > 0 → Le système utilise le swap = mémoire insuffisante
• so élevé → Écriture vers le swap, très lent

Étape 3 : Vérifier les erreurs (OOM-Killer)

dmesg | grep -i oom

Out of memory: Kill process 1234 (java) score 987
Killed process 1234 (java) total-vm:20480000kB

Si vous voyez ce message, le noyau a tué un processus par manque de mémoire. C’est critique.

Corrections possibles

1. Identifier les consommateurs :

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

2. Ajouter de la RAM si la charge est légitime.

3. Limiter les caches applicatifs (MySQL innodb_buffer_pool_size, Java Xmx).

4. Ajouter du swap sur SSD en cas d’urgence :

   dd if=/dev/zero of=/swapfile bs=1G count=4
   mkswap /swapfile && swapon /swapfile

Diagnostic disque (IO)

Le disque est souvent le composant le plus lent d’un serveur. Même un SSD est 1000 fois plus lent que la RAM. Quand le disque est saturé, tout le système en souffre.

Pourquoi le disque est-il si critique ?

Chaque fois qu’un programme lit ou écrit un fichier, il fait une opération I/O (Input/Output). Ces opérations incluent :

• Lecture de fichiers de configuration
• Écriture de logs
• Requêtes de base de données
• Swap (mémoire → disque)

Vitesses comparées

Composant	Temps d’accès	Analogie
CPU (cache L1)	1 ns	Clin d’œil
RAM	100 ns	Respiration
SSD NVMe	100 000 ns	Faire le tour du pâté de maisons
HDD	10 000 000 ns	Voyage Paris-Lyon en voiture

Glissez pour voir

Un disque saturé peut ralentir tout le système, même si le CPU et la RAM sont disponibles.

Étape 1 : Vérifier l’utilisation

iostat -dx 2 3

Décortiquons cette commande :

• iostat : statistiques d’entrées/sorties
• -d : afficher les stats disque (pas CPU)
• -x : affichage étendu avec plus de métriques
• 2 : rafraîchir toutes les 2 secondes
• 3 : pendant 3 itérations

Device    r/s    w/s   rkB/s   wkB/s  %util
sda      100     80    4000    2048   95.00

Que signifie chaque colonne ?

Colonne	Signification	Dans notre exemple
r/s	Lectures par seconde	100 ops/s
w/s	Écritures par seconde	80 ops/s
rkB/s	Débit lecture (Ko/s)	4 Mo/s
wkB/s	Débit écriture (Ko/s)	2 Mo/s
%util	% du temps où le disque travaille	95%

Glissez pour voir

La colonne %util est clé :

• < 70% → OK
• 70-90% → À surveiller
• > 90% → Goulot d’étranglement

Étape 2 : Identifier les processus

iotop

Total DISK READ: 12.00 M/s | Total DISK WRITE: 3.00 M/s
  PID  USER     DISK READ  DISK WRITE  COMMAND
 2345  mysql     8.00 M/s   1.00 M/s   mysqld

Étape 3 : Vérifier les erreurs disque

smartctl -a /dev/sda | grep -E "Reallocated|Error"

Reallocated_Sector_Ct: 12
Reported_Uncorrect: 3

Si ces valeurs augmentent, le disque est en train de mourir.

Corrections possibles

1. Migrer vers un SSD/NVMe pour les workloads intensifs.

2. Optimiser les requêtes de base de données (index manquants).

3. Activer le caching applicatif (Redis, Varnish).

4. Changer le scheduler IO pour les SSD :

   echo none > /sys/block/sda/queue/scheduler

Diagnostic réseau

Le réseau connecte votre serveur au monde extérieur. Un problème réseau peut ressembler à un problème applicatif (timeouts, lenteurs), ce qui le rend parfois difficile à identifier.

Types de problèmes réseau

Problème	Symptôme	Cause typique
Bande passante saturée	Transferts lents	Trop de trafic, attaque DDoS
Paquets perdus	Connexions instables	Réseau physique défaillant
Connexions refusées	”Connection refused”	Port fermé, limite atteinte
Latence élevée	Réponses lentes	Réseau congestionné, routage

Glissez pour voir

Étape 1 : Vérifier l’utilisation

ip -s link show eth0

Cette commande affiche les statistiques de l’interface réseau eth0 (adaptez le nom à votre serveur : ens3, enp0s3, etc.).

RX: bytes 1234567890 packets 12345678
TX: bytes 9876543210 packets 9876543
RX errors 0 dropped 10
TX errors 0 dropped 2

Décryptage :

Ligne	Signification	À surveiller
RX	Réception (trafic entrant)	Volume de données reçues
TX	Transmission (trafic sortant)	Volume de données envoyées
errors	Paquets corrompus	> 0 = problème physique
dropped	Paquets abandonnés	> 0 = saturation ou config

Glissez pour voir

Paquets dropped

Des paquets dropped indiquent que le système n’a pas pu traiter certains paquets. Causes possibles :

• File d’attente réseau pleine (saturation)
• Règles firewall
• Buffer réseau trop petit

Étape 2 : Vérifier la saturation des connexions

ss -s

Cette commande (socket statistics) donne un résumé des connexions réseau.

TCP: 145 (estab 120, closed 15, timewait 5)

Que signifient ces états ?

État	Signification	Problème si…
estab	Connexions actives	Nombre très élevé (> 10000)
closed	Connexions fermées récemment	Normal
timewait	En attente de fermeture complète	> 1000 = fuite de connexions

Glissez pour voir

Étape 3 : Identifier le trafic

iftop -i eth0

Ou pour voir par processus :

nethogs eth0

Corrections possibles

1. Optimiser les paramètres TCP :

   sysctl -w net.ipv4.tcp_tw_reuse=1
   sysctl -w net.ipv4.tcp_fin_timeout=15

2. Limiter les connexions avec iptables/firewalld.

3. Utiliser un CDN pour le contenu statique.

4. Augmenter la bande passante si légitime.

Installer les outils de diagnostic

Certaines commandes ne sont pas installées par défaut. Voici comment les obtenir :

Ubuntu/Debian

sudo apt update
sudo apt install sysstat iotop nethogs iftop smartmontools

Rocky/RHEL

sudo dnf install sysstat iotop nethogs iftop smartmontools

Ce que chaque paquet apporte :

Paquet	Commandes	Usage
sysstat	mpstat, iostat, sar	Métriques CPU, disque, historique
iotop	iotop	I/O par processus (comme top pour le disque)
nethogs	nethogs	Bande passante par processus
iftop	iftop	Trafic réseau en temps réel
smartmontools	smartctl	Santé des disques (S.M.A.R.T.)

Glissez pour voir

Tableau récapitulatif : diagnostic rapide

Ressource	Commande rapide	Ce qui indique un problème
CPU	uptime	Load > nombre de cœurs
CPU	mpstat 1	%idle < 10%
Mémoire	free -h	available < 10% total
Mémoire	vmstat 1	si/so > 0
Disque	iostat -dx 1	%util > 90%
Disque	vmstat 1	wa > 20%
Réseau	ip -s link	errors/dropped > 0
Réseau	ss -s	timewait élevé

Glissez pour voir

Dépannage

Symptôme	Cause probable	Solution
Load average élevé, CPU idle élevé	Attente IO (disque lent)	Vérifier iostat, migrer sur SSD
Swap utilisé, OOM dans dmesg	Mémoire insuffisante	Ajouter RAM ou limiter applications
%iowait élevé	Base de données non optimisée	Ajouter des index, caching
Connexions refusées	Limite de fichiers atteinte	ulimit -n et /etc/security/limits.conf

Glissez pour voir

À retenir

• La méthode USE (Utilization, Saturation, Errors) permet un diagnostic systématique.
• Le load average doit être divisé par le nombre de cœurs pour être interprété.
• %iowait élevé indique un problème disque, pas CPU.
• Swap actif = mémoire insuffisante, à corriger rapidement.
• %util > 90% sur iostat signifie que le disque est le goulot d’étranglement.
• Surveillez proactivement avec Prometheus/Grafana pour anticiper les problèmes.

Prochaines étapes

Installer Prometheus et Grafana Mettez en place une surveillance proactive de vos serveurs

Durcissement Linux Sécurisez et optimisez la configuration de votre serveur

Gestion des disques Linux Maîtrisez LVM, RAID et les systèmes de fichiers

Comprendre les processus Linux Approfondissez la gestion des processus et signaux

×

📖 Voir la documentation →