Vérifier la charge système sous Linux avec uptime et vmstat

Le load average mesure le nombre moyen de processus en attente d'exécution ou d'I/O sur 1, 5 et 15 minutes. Pour l'interpréter, divisez-le par le nombre de cœurs CPU (nproc) : un ratio supérieur à 1.0 signifie que le système est surchargé. Ce guide s'adresse à l'administrateur face à un serveur lent qui doit trancher vite entre trois coupables : le CPU, la mémoire ou les disques. Il enchaîne uptime, vmstat, top, free et /proc/pressure dans une méthode de diagnostic en cinq étapes, puis une alerte en script. Les commandes viennent du paquet procps, présent sur toute installation serveur mais absent des images conteneur minimales, comme celle de Debian 13.

Ce que vous allez apprendre

• Lire le load average avec uptime et /proc/loadavg
• Interpréter les 3 valeurs par rapport au nombre de cœurs CPU
• Distinguer surcharge CPU, surcharge I/O et saturation mémoire
• Diagnostiquer en temps réel avec vmstat, top et /proc/pressure
• Identifier les processus responsables de la surcharge
• Mettre en place une alerte simple en script

Dans quel contexte ?

La vérification de la charge système intervient dans de nombreuses situations :

• Un serveur web répond lentement, vous devez déterminer rapidement si c'est un problème CPU, mémoire ou disque
• Après un déploiement, vous vérifiez que l'application ne sature pas les ressources
• Une alerte monitoring signale un load average élevé, vous devez qualifier la nature du problème
• Vous préparez un dimensionnement : combien de cœurs et de RAM sont réellement utilisés ?
• En entretien ou en examen, on vous demande de diagnostiquer un serveur lent, la charge système est le premier réflexe

LFCS / RHCSA

Le référentiel RHCSA sur RHEL 10 demande d'identifier les processus gourmands en CPU ou en mémoire et de les arrêter, dans la section Operate running systems. Le LFCS range le sujet dans diagnose, identify, manage, and troubleshoot processes and services. Dans les deux cas, uptime, top et vmstat sont les premiers outils à sortir.

Le load average, uptime

Lire la charge en un coup d'œil

uptime répond en une ligne : depuis combien de temps la machine tourne, combien d'utilisateurs sont connectés, et les trois moyennes de charge.

uptime

 08:13:36 up 14 days, 22:25,  4 users,  load average: 0,50, 0,53, 0,41

Les trois valeurs sont la charge moyenne sur 1 minute, 5 minutes et 15 minutes. Les virgules décimales viennent d'une locale française ; en locale anglaise, uptime affiche 0.50, 0.53, 0.41, comme /proc/loadavg.

Lire depuis /proc/loadavg

uptime reformate en réalité un fichier que le noyau tient à jour en permanence : /proc/loadavg. Le lire directement est utile en script, car les deux dernières colonnes que uptime masque donnent des informations supplémentaires, notamment le nombre de processus actuellement exécutables. La première valeur reste le load average à 1 minute, exactement comme dans uptime.

cat /proc/loadavg

0.50 0.53 0.41 1/2509 2953827

Valeur	Signification
0.50	Load average 1 minute
0.53	Load average 5 minutes
0.41	Load average 15 minutes
1/2509	1 processus en cours d'exécution sur 2509 existants
2953827	Dernier PID attribué

Glissez pour voir

Interpréter le load average

Le load average représente le nombre moyen de processus qui sont soit en cours d'exécution (CPU), soit en attente non interruptible (état D), c'est-à-dire presque toujours une I/O disque ou un partage NFS. Une attente réseau ordinaire n'y entre pas : un processus bloqué sur une connexion TCP reste en état S, mesuré sur Debian 13. Pour l'interpréter, il faut le rapporter au nombre de cœurs :

nproc

16

Load average	Cœurs	Ratio	Interprétation
0,50	16	0,03	Système très peu chargé
8,00	16	0,50	Charge modérée (50 %)
16,00	16	1,00	Tous les cœurs occupés, seuil critique
32,00	16	2,00	File d'attente, processus ralentis

Glissez pour voir

La règle simple

Load / nproc < 0,7 → système confortable. > 1,0 → surcharge. > 2,0 → problème à résoudre rapidement. Regardez la valeur à 15 minutes pour la tendance de fond, celle à 1 minute pour l'état instantané.

Tendance : ce que révèle l'écart entre les 3 valeurs

Une seule valeur de load ne dit rien de la direction. La force des trois mesures (1, 5 et 15 minutes) est de montrer si la charge monte ou descend : il suffit de comparer leur ordre de grandeur. Lisez-les de gauche à droite, du plus récent au plus ancien. Ce réflexe évite une erreur classique en astreinte, paniquer sur un load à 1 minute élevé alors que les valeurs à 5 et 15 minutes montrent un pic déjà en train de retomber.

Pattern	Signification
1min > 5min > 15min	La charge monte, quelque chose vient de démarrer
1min < 5min < 15min	La charge descend, le pic est passé
Les 3 valeurs proches	Charge stable depuis 15 minutes
1min très élevé, 15min normal	Pic ponctuel, probablement un batch ou un déploiement

Glissez pour voir

Charge CPU ou charge I/O ?

Un load average élevé ne signifie pas forcément que le CPU est surchargé. Les processus en attente d'I/O disque comptent aussi. Deux outils permettent de les distinguer.

Avec vmstat

vmstat affiche une ligne par intervalle : ici cinq mesures espacées d'une seconde. Ignorez la première ligne, qui fait la moyenne depuis le démarrage, et lisez les suivantes.

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 gu
 0  0 272128 7061744 4444732 21433220  0    1    61   561 15162   23  4  2 94  0  0  0
 0  0 272128 7061384 4444732 21433280  0    0     0     0 2274 3284  1  1 99  0  0  0
 0  0 272128 7055740 4444732 21433296  0    0     0   136 2615 17379  1  1 98  0  0  0

Colonne	Signification	Ce qu'il faut regarder
r	Processus en cours (run queue)	Si r > nproc → CPU saturé
b	Processus bloqués sur I/O	Si b > 0 régulièrement → problème disque
us	% CPU utilisateur	Travail applicatif
sy	% CPU système	Travail noyau
id	% CPU idle	Temps libre
wa	% CPU en attente I/O	Le signal clé : wa élevé = goulot disque
si/so	Swap in / Swap out	Si > 0 → mémoire insuffisante

Glissez pour voir

Le piège du wa (I/O wait)

Un load average de 20 avec wa à 60 % et id à 35 % ne signifie pas que le CPU est surchargé. C'est le disque qui est le goulot. Ajouter des cœurs CPU ne résoudra rien, il faut un disque plus rapide (SSD) ou optimiser les I/O.

Avec top

top en mode batch (-b) avec une seule itération (-n1) donne un instantané à coller dans un ticket. Ses cinq premières lignes résument toute la machine.

top -bn1 | head -5

top - 08:13:38 up 14 days, 22:26,  4 users,  load average: 0,50, 0,53, 0,41
Tasks: 472 total,   1 running, 471 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1,1 us,  1,1 sy,  0,0 ni, 97,7 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Mem :  47953,2 total,   6890,4 free,  16420,6 used,  25271,6 buff/cache
MiB Swap:   4096,0 total,   3830,2 free,    265,8 used.  31532,6 avail Mem

La ligne %Cpu(s) donne la répartition en un coup d'œil : id élevé = système tranquille, wa élevé = problème I/O.

Identifier les processus gourmands

Une fois la ressource saturée connue, ps trié sur la bonne colonne nomme le processus responsable.

# Par CPU
ps aux --sort=-%cpu | head -10

# Par mémoire
ps aux --sort=-%mem | head -10

Dans top, appuyez sur P pour trier par CPU ou M pour trier par mémoire.

Vérifier la mémoire et le swap

free -h affiche la mémoire en unités lisibles. La colonne available compte plus que free, pour une raison détaillée juste en dessous.

free -h

               total        used        free      shared  buff/cache   available
Mem:            46Gi        16Gi       6,6Gi        33Mi        24Gi        30Gi
Swap:          4,0Gi       265Mi       3,7Gi

Valeur	Ce qu'il faut regarder
available	Mémoire réellement utilisable (inclut le cache récupérable)
Swap used	Si > 0, le système a manqué de RAM à un moment

Glissez pour voir

Ne pas confondre free et available

free montre la mémoire non utilisée du tout. available inclut le cache que Linux libérera si nécessaire. C'est available qui indique la marge réelle.

Vérifier si l'OOM killer est intervenu

Quand la mémoire manque, l'OOM killer (Out Of Memory) du noyau tue des processus pour survivre, et le consigne dans le journal du noyau :

sudo dmesg | grep -i "out of memory"

Si des lignes apparaissent, le système a dû tuer des processus par manque de mémoire, c'est un signal critique.

PSI, Pressure Stall Information (noyaux récents)

Sur les noyaux Linux 4.20+, /proc/pressure/ donne un indicateur précis de la pression sur chaque ressource :

cat /proc/pressure/cpu

some avg10=0.00 avg60=0.04 avg300=0.01 total=16325330830
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

cat /proc/pressure/memory

some avg10=0.00 avg60=0.00 avg300=0.00 total=3943556
full avg10=0.00 avg60=0.00 avg300=0.00 total=3814571

cat /proc/pressure/io

some avg10=0.04 avg60=0.23 avg300=0.09 total=1144701447
full avg10=0.03 avg60=0.21 avg300=0.09 total=1058047928

Fichier	some	full
cpu	Au moins un processus attend du CPU	Présent depuis le noyau 5.13, mais reste proche de 0 par construction
memory	Au moins un processus attend de la mémoire	Tous les processus attendent
io	Au moins un processus attend une I/O	Tous les processus attendent

Glissez pour voir

La ligne full du fichier cpu existe bien sur les noyaux récents, l'exemple ci-dessus le montre avec total=0. Elle reste quasi nulle : un processus prêt à s'exécuter finit toujours par obtenir du CPU, la notion de blocage total y a donc peu de sens. Sur memory et io, en revanche, un full non négligeable signale que tout le système est à l'arrêt en attente de la ressource, c'est le signal le plus grave.

Les valeurs avg10, avg60, avg300 sont les moyennes sur 10, 60 et 300 secondes (en % du temps). Comme repère empirique, et non comme seuil officiel, une valeur qui reste au-dessus de 5 % mérite investigation.

Diagnostic rapide, méthodologie

Les cinq étapes ci-dessous vont de la vue d'ensemble au coupable. Chacune décide si la suivante est utile : un ratio load/nproc sous 1 clôt souvent l'enquête dès la première.

1. Charge globale

   uptime
   nproc

   Calculez le ratio load/nproc. Si > 1, continuez le diagnostic.

2. CPU ou I/O ?

   vmstat 1 5

   Regardez wa (I/O wait) et r (run queue). Si wa > 20 % → problème disque. Si r > nproc → CPU saturé.

3. Mémoire

   free -h

   Si available est très faible ou Swap used est élevé → mémoire insuffisante.

4. Identifier le coupable

   ps aux --sort=-%cpu | head -5
   ps aux --sort=-%mem | head -5

5. Vérifier l'historique

   sudo dmesg | grep -i "out of memory"
   journalctl --since "1 hour ago" -p err

Alerte simple en script

Un contrôle automatique n'a besoin que de deux chiffres, le load à 1 minute et le nombre de cœurs, et d'une comparaison décimale. Bash ne sait comparer que des entiers : la version ci-dessous confie la comparaison à awk, présent partout, plutôt qu'à bc, absent d'une Debian 13 minimale.

#!/bin/bash
# Alerte si la charge dépasse le nombre de cœurs
LOAD=$(awk '{print $1}' /proc/loadavg)
CPUS=$(nproc)

if awk -v l="$LOAD" -v c="$CPUS" 'BEGIN { exit !(l > c) }'; then
    logger -p user.warning "ALERTE : load $LOAD dépasse $CPUS cœurs sur $(hostname)"
fi

L'alerte part dans le journal système avec logger, où votre supervision la récupère : journalctl -p warning --since today la montre. Un envoi par courriel (mail) suppose un serveur de messagerie configuré sur la machine, ce qui est rarement le cas. Planifiez ce script avec un timer systemd ou cron toutes les 5 minutes.

Dépannage

Ce tableau relie chaque symptôme observable à sa cause la plus probable. Lisez d'abord la colonne du milieu : les deux premières lignes affichent le même symptôme apparent, un load élevé, mais renvoient à des causes opposées, le disque dans un cas, le CPU dans l'autre. La ligne à ne pas manquer est l'avant-dernière, load à 0 mais serveur lent : elle rappelle que le load average ignore complètement la latence réseau et applicative.

Symptôme	Cause probable	Solution
Load élevé, CPU idle élevé	Processus bloqués sur I/O disque	vmstat : vérifier wa et b, migrer sur SSD
Load élevé, wa faible, us élevé	Charge CPU réelle	Identifier le processus avec top (touche P)
Swap utilisé en permanence	RAM insuffisante	Ajouter de la RAM ou réduire le nombre de services
OOM killer dans dmesg	Mémoire épuisée, processus tués	Augmenter RAM, configurer les limites cgroups
Load à 0 mais serveur lent	Problème réseau ou applicatif	Vérifier ss -tulpn, les latences réseau
Load monte par pic régulier	Cron ou batch planifié	crontab -l, systemctl list-timers pour identifier

Glissez pour voir

À retenir

• Le load average = nombre moyen de processus en exécution ou en attente d'I/O, divisez-le par nproc pour interpréter
• Trois valeurs (1, 5, 15 min) donnent la tendance : en hausse, stable ou en baisse
• wa dans vmstat est le signal clé pour distinguer surcharge CPU et surcharge I/O disque
• free -h : regardez available, pas free, pour évaluer la marge mémoire restante
• PSI (/proc/pressure/) donne la pression réelle sur CPU, mémoire et I/O sur les noyaux récents
• Un load > nproc n'est pas toujours un problème CPU, vérifiez toujours wa et swap avant de conclure
• En production, mettez en place une surveillance automatisée (Prometheus/Grafana) plutôt que des vérifications manuelles

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →