Faut-il désactiver le swap sur un serveur ? La réponse honnête

Le conseil de désactiver le swap circule depuis vingt ans. Ce qu'il coûte réellement, pourquoi le swappiness ne fait pas ce qu'on croit, et les rares cas où la désactivation est justifiée.

Le conseil circule depuis vingt ans : sur un serveur correctement dimensionné, désactivez le swap. Il paraît solide — si la mémoire suffit, pourquoi utiliser un disque mille fois plus lent ?

Il repose sur une confusion : le swap remplit deux rôles distincts, et le raisonnement n'en considère qu'un seul.

Les deux rôles du swap

Rôle un : la soupape. Quand la mémoire manque, le swap évite l'arrêt brutal en déplaçant des pages sur disque. C'est le rôle que tout le monde connaît, et effectivement, avec assez de mémoire, il ne devrait jamais servir.

Rôle deux : l'optimisation. C'est celui qu'on oublie. Un système en fonctionnement accumule des pages allouées mais jamais relues : données d'initialisation, bibliothèques chargées puis inutilisées, démons dormants qui ne se réveilleront pas avant des jours.

Ces pages occupent de la mémoire vive sans rendre le moindre service. Avec du swap, le noyau les déplace sur disque et récupère cette mémoire pour le cache disque.

Et le cache disque, lui, accélère tout. Chaque mégaoctet rendu au cache évite des lectures physiques.

Le paradoxe : sans swap, des pages inertes squattent la mémoire vive au détriment du cache. Vous n'avez pas plus de mémoire utile — vous l'utilisez moins bien.

Le swappiness ne fait pas ce que vous croyez

Le réglage le plus commenté est aussi le plus mal compris. La croyance répandue : ce serait un pourcentage d'occupation mémoire à partir duquel le système commence à swapper.

Ce n'est pas cela. Ce paramètre exprime un arbitrage : lorsque le noyau doit libérer de la mémoire, préfère-t-il évincer du cache disque ou des pages anonymes ?

Une valeur basse le pousse à sacrifier le cache. Une valeur haute à sacrifier des pages anonymes vers le swap. Aucun seuil de déclenchement n'est défini nulle part.

Conséquence pratique : le régler à zéro ne désactive pas le swap. Cela indique de n'y recourir qu'en dernier recours — ce qui, sous forte pression, arrivera de toute façon.

Et une valeur très basse a un effet pervers : le noyau préfère jeter du cache disque, y compris du cache très utile, plutôt que de déplacer des pages qui dorment depuis trois semaines. Vous conservez en mémoire ce qui ne sert pas, et vous relisez sur disque ce qui sert.

Le swap est un symptôme, pas une cause

Le raisonnement le plus fréquent : « le serveur rame, le swap est utilisé, donc c'est le swap. »

C'est l'inverse. Si le système échange activement des pages en permanence, c'est que la mémoire physique ne suffit plus. Le swap ne cause pas la lenteur : il la rend visible, tout en amortissant une situation qui, sans lui, se solderait par des processus tués.

D'où une distinction essentielle en diagnostic :

  • Le volume de swap occupé est souvent bénin. Quelques centaines de mégaoctets sur un serveur qui tourne depuis des mois, ce sont des pages inertes correctement rangées. Rien à faire.
  • L'activité d'échange — des pages qui entrent et sortent en continu — est le vrai signal. C'est elle qui indique une pénurie réelle.

Surveillez le débit d'échange, pas l'espace occupé. Une alerte sur le second génère des faux positifs permanents.

Les cas où désactiver se justifie

Deux situations légitimes.

Les charges à latence garantie. Traitement temps réel, base de données entièrement en mémoire, application où un accès disque imprévu casse un engagement de service. Là, mieux vaut un échec franc et immédiat qu'une latence erratique impossible à expliquer.

Certains orchestrateurs de conteneurs. Plusieurs exigent la désactivation, pour une raison défendable : le swap rend les limites mémoire des conteneurs imprévisibles et fausse les décisions de placement. Un conteneur censé être limité à deux gigaoctets qui en utilise trois via le swap casse tout le modèle de planification.

Hors de ces cas, la désactivation apporte rarement le gain espéré, et coûte souvent du cache disque.

La compression en mémoire, bon compromis

Il existe une voie intermédiaire trop peu utilisée : compresser les pages en mémoire au lieu de les écrire sur disque.

Les pages candidates au swap sont compressées et conservées dans une zone dédiée de la mémoire vive. On récupère de la place sans subir la latence disque, au prix d'un peu de CPU — ressource généralement disponible sur un serveur limité en mémoire.

Sur une machine qui subit des pics ponctuels, cela absorbe l'essentiel avec une pénalité sans commune mesure avec celle d'un swap classique. Ce n'est pas un substitut à de la mémoire manquante, mais c'est une couche intermédiaire efficace.

La recommandation

Gardez du swap, dimensionné modestement — quelques gigaoctets suffisent sur un serveur bien pourvu. Son but n'est pas de compenser un manque, mais de laisser au noyau la liberté de ranger ce qui ne sert pas.

Laissez le swappiness à sa valeur par défaut, sauf mesure contraire sur votre charge réelle. Surveillez l'activité d'échange plutôt que le volume occupé. Et si cette activité est soutenue, ne touchez pas au swap : ajoutez de la mémoire. C'est le seul réglage qui traite la cause.

Questions fréquentes

À quoi sert le swap si j'ai largement assez de RAM ?
À évacuer les pages allouées mais jamais utilisées. Un système en fonctionnement accumule des mégaoctets de données d'initialisation, de bibliothèques chargées et jamais appelées, de démons inactifs. Sans swap, tout cela occupe de la mémoire vive en pure perte. Avec swap, le noyau les déplace sur disque et rend cette mémoire au cache disque, qui accélère toutes vos lectures. Le swap sert donc aussi les machines qui ont de la marge.
Le swappiness est-il un pourcentage de mémoire avant de commencer à swapper ?
Non, c'est le malentendu le plus répandu. Ce paramètre exprime un arbitrage : quand le noyau doit libérer de la mémoire, préfère-t-il évincer du cache disque ou des pages anonymes ? Une valeur basse le pousse vers le cache, une valeur haute vers le swap. Il ne définit aucun seuil de déclenchement. Le régler à zéro ne désactive d'ailleurs pas le swap : cela indique de n'y recourir qu'en dernier ressort.
Mon serveur rame et le swap est utilisé : est-ce la cause ?
C'est presque toujours l'inverse : le swap est le symptôme, pas la cause. Si le système déplace activement des pages en permanence, c'est que la mémoire physique ne suffit plus à la charge. Désactiver le swap dans cette situation ne rend rien plus rapide : cela remplace une lenteur par des processus tués par le noyau. Distinguez toujours le volume de swap occupé — souvent bénin, ce sont des pages inertes — de l'activité d'échange, qui, elle, est le vrai signal d'alerte.
Quand la désactivation est-elle réellement justifiée ?
Deux cas principalement. Les charges à latence garantie, où un accès disque imprévisible est inacceptable — traitement temps réel, certaines bases en mémoire — préfèrent un échec franc à une latence erratique. Et certains orchestrateurs de conteneurs qui exigent la désactivation, parce que le swap rend les limites mémoire imprévisibles et fausse la planification. En dehors de ces cas, la désactivation est rarement un gain.
Le zswap ou la compression en mémoire sont-ils une meilleure option ?
C'est souvent un excellent compromis. Le principe est de compresser les pages en mémoire plutôt que de les écrire sur disque : on y gagne de la place sans subir la latence d'un accès disque. Sur une machine dotée de CPU disponible, cela absorbe l'essentiel des pics avec une pénalité très inférieure à celle d'un swap classique. Ce n'est pas un substitut complet à de la mémoire manquante, mais c'est une couche intermédiaire utile.

Cet article vous a plu ?

Commentaires

Morgann Riu

Expert en cybersécurité et administration Linux. J'aide les entreprises à sécuriser et optimiser leurs infrastructures critiques.

Retour au blog

Checklist Sécurité Linux

30 points essentiels pour sécuriser un serveur Linux. Recevez aussi les nouveaux tutoriels par email.

Pas de spam. Désabonnement en 1 clic.