Diagnostiquer la mémoire sous Linux

Sur Linux, la mémoire n’est pas ce que free semble dire. Un serveur qui affiche 90 % de mémoire utilisée est probablement en parfaite santé — ce que vous voyez, c’est le cache. La compétence à acquérir en diagnostic mémoire est de lire les bons champs (available plutôt que free), d’identifier les processus qui consomment vraiment, et d’anticiper la pression mémoire avant que l’OOM killer ne tue un service critique. Ce guide trace la boucle complète : vue d’ensemble, détail, processus, temps, action.

Ce que vous allez apprendre

Distinguer used, free, available, buff/cache et swap dans free -h
Lire les champs essentiels de /proc/meminfo sans vous noyer dans la soixantaine de lignes
Identifier les processus qui consomment vraiment la RAM avec ps et top/htop
Observer l’évolution avec vmstat et sar -r
Agir : fichier swap, swappiness, purge de cache
Anticiper l’OOM killer et réagir quand il frappe

Dans quel contexte ?

Ce diagnostic sert dans trois scénarios fréquents :

Un service vient d’être tué — le journal mentionne Out of memory: Killed process. Il faut retrouver qui consommait, pourquoi, et si la machine est sous-dimensionnée.
Le serveur ralentit sans raison évidente — pic de swap, contention mémoire, un processus qui fuit progressivement.
Préparation d’un dimensionnement — avant d’ajouter un service, vérifier la marge disponible et la posture swap.

C’est une compétence LFCS (domaine Essential Commands and System Operations) et RHCSA (Operate running systems).

Prérequis

Un terminal avec droits sudo
Les bases de processus Linux
Installer htop et sysstat (pour sar) si absents :

Debian / Ubuntu
RHEL / Fedora / Rocky

sudo apt update
sudo apt install -y htop sysstat

sudo dnf install -y htop sysstat
sudo systemctl enable --now sysstat

Le modèle mémoire en 5 minutes

Avant de lire les commandes, cinq concepts suffisent.

RAM physique. La mémoire vive de la machine, limite physique stricte.

Mémoire virtuelle. Chaque processus a son propre espace d’adresses virtuel, mappé à la RAM par le noyau. Les pages non utilisées peuvent migrer vers le disque (swap).

Buffers et cache. Linux garde en RAM ce qui a été lu ou écrit récemment sur disque. Cette mémoire est immédiatement récupérable dès qu’un processus en a besoin — free la compte dans used, mais available la compte comme disponible. Ne confondez pas les deux.

Swap. Extension disque de la mémoire. Quand la RAM sature, des pages peu actives y sont écrites pour libérer de la place. L’accès disque est 100 à 1000× plus lent que la RAM — un système qui swappe beaucoup ralentit fortement.

OOM killer. Quand RAM + swap sont saturées, le noyau tue un processus pour libérer de la mémoire et éviter le gel total. Le choix est piloté par le score /proc/<pid>/oom_score.

Vue d’ensemble avec `free`

La première commande, à lire de gauche à droite :

free -h

Sortie typique :

               total        used        free      shared  buff/cache   available
Mem:            31Gi       2.6Gi        25Gi        13Mi       3.9Gi        28Gi
Swap:          8.0Gi          0B       8.0Gi

Les colonnes qui comptent :

Colonne	Signification	À surveiller ?
`total`	RAM physique	Constante, sert de référence
`used`	Mémoire allouée aux processus plus buff/cache	Peut paraître élevée sans que ce soit anormal
`free`	Mémoire non utilisée du tout	Souvent basse — c’est normal
`buff/cache`	Caches I/O, récupérables à la demande	Élevé = système tire parti de la RAM
`available`	Ce qui peut être attribué à un nouveau processus	La vraie métrique santé
`Swap total/used`	Zone swap configurée / utilisée	Un `used` qui monte = pression mémoire

Détail via `/proc/meminfo`

free lit ses chiffres dans /proc/meminfo. Ce fichier expose ~60 champs ; 7 suffisent pour un diagnostic courant.

grep -E '^(MemTotal|MemFree|MemAvailable|Buffers|Cached|SwapTotal|SwapFree|Dirty|Writeback):' /proc/meminfo

Sortie typique :

MemTotal:       32602704 kB
MemFree:        26288324 kB
MemAvailable:   29867396 kB
Buffers:          511084 kB
Cached:          3327372 kB
SwapTotal:       8388604 kB
SwapFree:        8388604 kB
Dirty:               252 kB
Writeback:             0 kB

Les champs à retenir :

MemAvailable — ce que le noyau estime allouable à un nouveau processus, en tenant compte des caches récupérables. C’est cette valeur qui compte, pas MemFree.
Buffers + Cached — mémoire récupérable. Une chute brutale signale une demande forte.
SwapFree — si proche de zéro, l’OOM killer approche.
Dirty — pages modifiées en attente d’écriture disque. Une valeur haute persistante = goulot d’étranglement I/O.

Identifier les processus gourmands

Avec `ps`

Trier par consommation RAM, dix premiers :

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

Colonnes clés :

Colonne	Signification
`USER`	Propriétaire du processus
`%MEM`	% de RAM physique utilisée
`VSZ`	Taille de l’espace virtuel (en Ki) — peut être trompeur, contient des pages mappées non chargées
`RSS`	Resident Set Size — mémoire physique réellement occupée (en Ki)
`COMMAND`	Commande ayant lancé le processus

Préférez RSS à VSZ pour savoir ce qu’un processus consomme vraiment.

Avec `top` / `htop`

top donne une vue temps réel :

top -o %MEM

Dans l’interface, M trie par mémoire, c montre la commande complète, f permet de choisir les colonnes affichées.

htop est plus lisible et intuitif :

htop

Les barres du haut visualisent la RAM et la swap ; la colonne MEM% trie par un simple clic ou par F6.

Comprendre la mémoire partagée avec `smem`

ps double-compte la mémoire partagée entre plusieurs processus. smem expose le Proportional Set Size (PSS) — la part réellement imputable à chaque processus :

sudo smem -rs pss | head -n 10

Colonne	Signification
`USS`	Mémoire unique au processus
`PSS`	Part proportionnelle des pages partagées + USS
`RSS`	Totalité, double comptée si pages partagées

C’est indispensable pour diagnostiquer un serveur qui héberge beaucoup de processus d’une même application (Apache, PostgreSQL…).

Observer dans le temps

`vmstat` — snapshot toutes les N secondes

vmstat 2 5

(Cinq relevés espacés de deux secondes.)

Colonnes essentielles pour la mémoire :

Colonne	Signification
`free`	Mémoire non utilisée
`buff` / `cache`	Buffers et cache
`si` / `so`	Swap in / out par seconde — activité swap en direct
`r`	Processus en attente d’exécution
`b`	Processus bloqués sur I/O

`sar -r` — historique

sar (paquet sysstat) collecte des métriques en continu et permet de revenir en arrière :

# Temps réel : 3 relevés espacés de 1 s
sar -r 1 3

# Historique de la journée
sar -r

# Historique d'un jour donné
sar -r -f /var/log/sysstat/sa$(date -d yesterday +%d)

Colonnes principales : kbmemfree, kbmemused, %memused, kbbuffers, kbcached, kbswpfree, kbswpused, %swpused. Indispensable pour un audit ou un post-mortem à froid.

Diagnostiquer une pression mémoire

Symptômes à croiser :

free -h montre available < 10 % de total
vmstat 2 affiche si/so non-nuls en continu
dmesg -T | tail -50 contient Out of memory: Killed process
Le load average grimpe sans que le CPU soit saturé — les processus attendent la mémoire

Commandes de diagnostic enchaînées :

# qui consomme ?
ps aux --sort=-%mem | head -n 10

# depuis quand ?
sar -r | tail -30

# swap actif ?
vmstat 2 5

# OOM killer déjà passé ?
sudo dmesg -T | grep -iE 'oom|killed'
journalctl -k --since "1 hour ago" | grep -iE 'oom|killed'

Si l’OOM killer a frappé, la ligne typique dans dmesg est :

Out of memory: Killed process 1234 (nginx) total-vm:512000kB, anon-rss:400000kB

On a alors le PID, le nom du processus, et sa consommation au moment du kill.

Agir sur la mémoire

Diagnostic posé, on peut intervenir. Les leviers se divisent en deux : ajuster la politique (swappiness, ajout de swap) ou libérer ponctuellement (drop_caches).

Ajuster la swappiness

vm.swappiness (0-100) règle l’agressivité du swap. Valeurs typiques :

10 — serveur de base de données, latence critique
60 — valeur par défaut, poste de travail
100 — swap au maximum (rare)

Modification runtime :

sudo sysctl vm.swappiness=10
cat /proc/sys/vm/swappiness

Persistance :

echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system

Ajouter un fichier swap

Utile sur un VPS sans partition swap. Avec un fichier d’1 Gi :

Créer le fichier et le sécuriser

sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile

Activer
Fenêtre de terminal
```
sudo swapon /swapfile
swapon --show
```

Persister dans /etc/fstab

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Vérifier après reboot

sudo systemctl reboot
# après reconnexion
swapon --show
free -h

Désactiver / réactiver temporairement

# tout désactiver
sudo swapoff -a

# tout réactiver (selon /etc/fstab)
sudo swapon -a

swapoff -a peut geler la machine si la RAM ne suffit pas à réintégrer les pages swappées. À utiliser avec prudence.

Purger le cache (rarement utile)

sudo sync
echo 3 | sudo tee /proc/sys/vm/drop_caches

Valeurs possibles : 1 (pagecache), 2 (dentry + inodes), 3 (tout). Utile pour des mesures de performance ou un test de régénération du cache — pas pour résoudre une pression mémoire, Linux libère déjà le cache automatiquement.

Bonnes pratiques

Lisez available, pas free. 90 % des erreurs de diagnostic viennent de là.
Surveillez si/so de vmstat pour détecter un swap chronique.
Gardez sysstat activé — sar sauve la mise pour les post-mortems.
Ne purgez pas le cache en production sauf test ciblé. Linux s’en charge.
Dimensionnez le swap : typiquement égal à la RAM jusqu’à 8 Gi, puis moitié au-dessus. Pour un serveur de base de données avec swappiness=1, un petit swap suffit comme filet.
Alertez sur MemAvailable et SwapUsed, pas sur MemFree.

Sécurité et rollback

La seule manipulation risquée du guide est swapoff -a quand la swap est en usage. Avant de désactiver la swap :

# vérifier qu'elle n'est pas utilisée
free -h
swapon --show

# si 'used' > 0, désactiver progressivement ou pas du tout

Les modifs de swappiness sont réversibles sans risque. Si un fichier swap n’est plus voulu :

sudo swapoff /swapfile
sudo sed -i '/\/swapfile/d' /etc/fstab
sudo rm /swapfile

Dépannage rapide

Symptôme	Cause probable	Action
`free` affiche `used` très haut mais tout va bien	`used` inclut buff/cache, lire `available` à la place	Interpréter différemment, pas d’intervention
`available` bas + `si/so` non-nul	Pression mémoire réelle	`ps aux --sort=-%mem` → identifier et limiter
OOM killer a tué un service	RAM+swap saturées	`dmesg -T
Swap remplie à 100 % mais `available` haut	Swap remplie historiquement, pas en usage actif	`swapoff -a && swapon -a` pour vider — seulement si RAM confortable
Swap ignorée sur VPS cloud	Image sans swap, `swapon --show` vide	Créer un fichier swap (cf. ci-dessus)
`htop` / `free` incohérents	Rare, cache `ps` vs lecture directe `/proc`	Croiser avec `cat /proc/meminfo`

À retenir

Lisez available, pas free. C’est la seule bonne métrique de RAM disponible.
Le cache remplit toujours la RAM — c’est sain, pas un problème.
Les champs critiques de /proc/meminfo : MemAvailable, Buffers+Cached, SwapFree.
ps aux --sort=-%mem et htop pour trouver les processus gourmands ; smem -s pss pour la part proportionnelle.
vmstat 2 : surveillez si/so. Non-nuls en continu = swap chronique.
sar -r préserve l’historique mémoire — indispensable pour les post-mortems.
vm.swappiness ajustable runtime (sysctl) et permanent (/etc/sysctl.d/).
Fichier swap utile sur VPS sans partition dédiée : fallocate + mkswap + swapon + entrée /etc/fstab.
OOM killer frappe quand RAM+swap saturées — le log est dans dmesg et journalctl -k.
Ne purgez pas drop_caches en production sauf test contrôlé.

Prochaines étapes

Évaluer les performances système Méthode USE, CPU, disque et réseau — la vision transverse au-delà de la mémoire.

Interpréter la charge système Lire le load average et corréler avec CPU, I/O et mémoire.

Gérer les processus Identifier, signaler et prioriser les processus Linux.

Espace disque et inodes L'autre pénurie classique : disque plein ou inodes épuisées.