Diagnostiquer la mémoire sous Linux

Sur Linux, la mémoire n'est pas ce qu'un pourcentage brut semble dire. Un monitoring qui affiche « 90 % de RAM utilisée » calcule souvent (total - free) / total : ce chiffre englobe le cache, récupérable à tout moment, et fait paniquer pour rien. La colonne used de free, elle, vaut total - available avec procps-ng 4.0.4 : elle laisse de côté le cache récupérable. La compétence à acquérir en diagnostic mémoire est de lire les bons champs (available plutôt que MemFree, used distinct de buff/cache), 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.

Les deux certifications l'évaluent. Le LFCS demande de « Monitor and troubleshoot system performance and services » (domaine Essential Commands) et de « Configure and manage swap space » (domaine Storage). Le RHCSA (EX200, RHEL 10) demande d'« Identify CPU/memory intensive processes and kill processes » et d'ajouter du « swap to a system non-destructively ».

Prérequis

• Un terminal avec droits sudo
• Les bases de processus Linux
• Installer htop et sysstat (pour sar) si absents, puis activer la collecte de sar, désactivée par défaut sur Debian et Ubuntu (ENABLED="false" dans /etc/default/sysstat, relevé sur Debian 13 et Ubuntu 24.04) :

Debian / Ubuntu

sudo apt update
sudo apt install -y htop sysstat
sudo sed -i 's/^ENABLED="false"/ENABLED="true"/' /etc/default/sysstat
sudo systemctl enable --now sysstat

RHEL / Fedora / Rocky

sudo dnf install -y epel-release   # htop vient d'EPEL sur RHEL 10
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. Le free moderne (procps-ng) la place dans sa propre colonne buff/cache et la compte dans available. Avec procps-ng 4.0.4, la colonne used se calcule comme total - available : mesuré sur Debian 13, Ubuntu 24.04 et AlmaLinux 10, la valeur de free -k tombe exactement sur MemTotal - MemAvailable. Autrement dit, used mesure la RAM qu'on ne peut pas récupérer, pas le cache. 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.

Le mythe de la RAM pleine

Une machine Linux saine utilise presque toute sa RAM en permanence, le cache remplit l'espace libre pour accélérer les I/O. Un serveur avec beaucoup de RAM "libre" gâche de la performance. Mais attention au sens de « pleine » : le mythe « t'inquiète, c'est du cache » vaut pour un chiffre calculé en (total - free) / total, ou un dashboard qui range buff/cache dans « utilisé ». Il ne vaut pas pour la colonne used de free, qui laisse déjà de côté le cache récupérable : un used élevé, lui, est une vraie occupation par les processus. La seule métrique de santé fiable reste available, complétée par l'activité du swap.

Vue d'ensemble avec free

La première commande, à lire de gauche à droite. Avec procps-ng 4.0.4, used et available se complètent : leur somme donne total.

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 non récupérable (total - available avec procps-ng 4.0.4)	Élevée = vraie pression, corréler avec available et swap
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

Glissez pour voir

Options utiles de free

• free -h, unités lisibles (Ki/Mi/Gi)
• free -s 2, rafraîchit toutes les 2 secondes (suivi en direct)
• free -t, ajoute une ligne Total combinant RAM + swap

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

Glissez pour voir

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. Il s'installe par apt install smem sur Debian et Ubuntu, mais n'existe pas pour RHEL 10, pas même dans EPEL (vérifié sur AlmaLinux 10) ; le champ Pss de /proc/<pid>/smaps_rollup donne alors la même mesure, processus par processus :

sudo smem -rs pss | head -n 10

# Sans smem : PSS d'un processus, en Ko
sudo grep '^Pss:' /proc/1234/smaps_rollup

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

Glissez pour voir

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

Glissez pour voir

Le signal à surveiller

Des colonnes si/so non-nulles en permanence = la machine swappe continuellement. Soit la RAM est sous-dimensionnée, soit un processus fuit progressivement. Ne laissez jamais un serveur production dans cet état.

sar -r, historique

sar (paquet sysstat) collecte des métriques en continu, une fois la collecte activée (voir les prérequis), et permet de revenir en arrière. Les fichiers quotidiens vivent dans /var/log/sysstat/ sur Debian et Ubuntu, dans /var/log/sa/ sur RHEL :

# 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é (/var/log/sa/ sur RHEL)
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 (format des noyaux récents, tronqué ici) :

Out of memory: Killed process 1234 (nginx) total-vm:512000kB, anon-rss:400000kB, file-rss:0kB, shmem-rss:0kB, UID:33 pgtables:1024kB oom_score_adj:0

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 du noyau, poste de travail
• 30 ou 10, valeurs posées par les profils tuned virtual-guest et throughput-performance (lu dans leurs fichiers tuned.conf) : sur une RHEL où tuned est actif, vérifiez la valeur réelle avant de conclure au défaut
• 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 :

1. Créer le fichier et le sécuriser

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

2. Activer

   sudo swapon /swapfile
   swapon --show

3. Persister dans /etc/fstab

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

4. 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

Ces règles reprennent les pièges mesurés plus haut, dans l'ordre où ils coûtent le plus cher : un chiffre mal lu déclenche une fausse alerte, une collecte sar oubliée laisse un post-mortem sans données, un swap mal dimensionné transforme un pic en incident.

• 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 selon l'usage : quelques Gio suffisent comme filet sur un serveur bien dimensionné, et un serveur de base de données avec swappiness basse n'en a besoin que pour absorber un pic. Il n'existe pas de règle universelle du type « swap = RAM ».
• 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

Lisez ce tableau par le symptôme : les deux premières lignes distinguent une fausse alerte d'un tableau de bord d'une vraie pression mémoire, qui se confirme toujours par available bas et un swap actif en même temps.

Symptôme	Cause probable	Action
Un dashboard affiche 90 %+ de RAM « utilisée » mais tout va bien	Le chiffre est (total - free), il englobe buff/cache récupérable	Lire les colonnes used et available de free, pas (total - free)
free affiche used très haut	Mémoire non récupérable (used = total - available)	Vérifier available et si/so : si bas + swap actif, pression réelle
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 | grep -i oom pour la victime, dimensionner RAM/swap ou ajuster oom_score_adj du service critique
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

Glissez pour voir

À 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 (ou Pss dans smaps_rollup sur RHEL) pour la part proportionnelle.
• Avec procps-ng 4.0.4, used vaut total - available : les deux colonnes se complètent.
• vmstat 2 : surveillez si/so. Non-nuls en continu = swap chronique.
• sar -r préserve l'historique mémoire, indispensable pour les post-mortems, à condition d'avoir activé la collecte (désactivée par défaut sur Debian et Ubuntu).
• 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é.

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 →