Ajouter du swap à un serveur qui manque de mémoire semble être une solution évidente : plus d’espace disponible avant qu’un processus ne soit tué. En pratique, le swap déplace souvent le problème vers une forme pire, un système qui devient inutilisable par thrashing, plutôt que de le résoudre proprement.

Ce que le swap fait réellement sous pression mémoire

Le kernel déplace vers le disque les pages mémoire les moins récemment utilisées quand la RAM physique vient à manquer, libérant de l’espace pour ce qui est actif. Ce mécanisme fonctionne bien pour des pages rarement accédées, mais devient un problème dès qu’un processus continue d’accéder activement à des pages qui ont été swappées : chaque accès déclenche une lecture disque, des ordres de grandeur plus lente qu’un accès RAM.

Le thrashing : le système entier devient inutilisable

Sous forte pression mémoire, plusieurs processus actifs peuvent finir par se disputer le même espace de swap : le kernel passe alors le plus clair de son temps à écrire et relire des pages depuis le disque plutôt qu’à exécuter du code applicatif, un état appelé thrashing. Contrairement à un processus tué proprement par l’OOM killer, un système en thrashing reste techniquement vivant, mais devient si lent que toute action (y compris une connexion SSH pour diagnostiquer le problème) peut prendre plusieurs minutes.

# Un système en thrashing montre une activité disque
# massive sans corrélation avec une charge applicative réelle
vmstat 1
# si si  bi   bo   in   cs us sy id wa
#  8  4 512  256 4000 8000  5 15  0 80
# wa (I/O wait) élevé = symptôme classique de thrashing

vm.swappiness : le curseur qui décide de l’agressivité

vm.swappiness (0 à 100, 60 par défaut sur beaucoup de distributions) contrôle à quel point le kernel préfère swapper des pages plutôt que de récupérer de la mémoire par d’autres moyens (réduire le cache disque, par exemple). Une valeur basse retarde le recours au swap, préférant réduire le cache système en premier ; une valeur élevée swappe plus tôt et plus agressivement.

# Valeur actuelle et ajustement temporaire
# (non persistant après redémarrage)
cat /proc/sys/vm/swappiness
sysctl vm.swappiness=10

La recommandation moderne : swap minimal ou nul sur les serveurs

Sur un serveur applicatif (par opposition à un poste de travail, où le swap absorbe des pics ponctuels sans nuire à la réactivité perçue), la pratique moderne penche souvent vers une swappiness très basse, voire l’absence totale de swap : laisser l’OOM killer agir rapidement et tuer proprement le processus le plus problématique vaut souvent mieux qu’un système qui thrashe indéfiniment sans jamais libérer réellement la pression mémoire.

# Désactiver complètement le swap,
# une pratique courante sur les serveurs de production
swapoff -a

Cette recommandation n’est pas universelle : une base de données ou une application avec des pics de mémoire ponctuels et courts peut légitimement bénéficier d’un peu de swap pour absorber ces pics sans déclencher l’OOM killer, un compromis à évaluer selon le profil réel de la charge, pas une règle à appliquer aveuglément.

À retenir

Le swap déplace la pression mémoire vers le disque, un mécanisme qui fonctionne pour des pages rarement accédées mais dégénère en thrashing quand plusieurs processus actifs se disputent le même espace : le système reste techniquement vivant, mais devient si lent que même le diagnostiquer devient difficile, souvent pire qu’un processus tué proprement par l’OOM killer. vm.swappiness contrôle l’agressivité du recours au swap, une valeur basse ou une désactivation complète étant souvent préférable sur un serveur applicatif moderne, au prix d’un OOM killer plus prompt à agir sur des pics de mémoire ponctuels. Ce compromis, rarement évident au premier abord, fait partie des réglages Linux qui comptent dès qu’un serveur tourne sous contrainte mémoire réelle.