Le swap Linux : éviter le crash de vos pipelines CI/CD quand la RAM manque

Un pipeline qui « passe » un jour et échoue le lendemain sans qu'une ligne de code n'ait changé : voilà un symptôme classique de manque de mémoire. Sur les petits serveurs, le swap est souvent le filet de sécurité qui transforme un crash en simple ralentissement. Cet article explique en détail ce qu'est le swap, quand l'utiliser, comment l'activer, et le déroule sur un cas concret : un pipeline GitLab CI/CD qui plantait sur un VPS trop juste en RAM.

Qu'est-ce que le swap, exactement ?

La mémoire vive (RAM) est rapide mais limitée. Le noyau Linux gère la mémoire par pages (blocs de 4 Ko en général) et présente aux programmes une mémoire virtuelle plus grande que la RAM physique. Le swap est un espace sur disque (fichier ou partition) où le noyau peut déplacer temporairement des pages de mémoire peu utilisées pour libérer de la RAM. C'est comme une « annexe » plus lente mais bien plus grande.

Le swap n'ajoute pas de la vraie RAM : il évite qu'un pic de mémoire ne fasse tuer un processus. On échange de la vitesse contre de la survie.

Deux mécanismes clés à connaître :

• L'OOM killer (Out Of Memory) : quand il n'y a plus ni RAM ni swap disponible, le noyau tue brutalement un processus pour sauver le système. C'est lui qui fait échouer les builds (signal SIGKILL, code de sortie 137, ou OOMKilled côté conteneur).
• La « swappiness » (vm.swappiness, 0–100) : règle l'empressement du noyau à utiliser le swap. Basse (10) = « n'y touche qu'en dernier recours » ; haute (60, défaut) = « swappe plus tôt ». Sur un serveur, une valeur basse garde les données chaudes en RAM.

Quand l'utiliser… et quand l'éviter

À activer quand :

• La RAM est limitée et des pics ponctuels surviennent (compilation, tests, imports, sauvegardes) ;
• Vous voulez un filet de sécurité contre l'OOM killer plutôt qu'un plantage ;
• Vous ne pouvez pas (ou pas tout de suite) ajouter de la RAM.

À éviter / nuancer quand :

• Vous en feriez un substitut permanent à la RAM : si l'appli swappe en continu, elle rame (le disque est ~100× plus lent que la RAM). Le swap est un tampon, pas une solution de capacité.
• Sur des bases de données très sensibles à la latence : trop de swap dégrade fortement les temps de réponse. On garde alors une swappiness basse et on dimensionne la RAM.
• Sur un SSD : c'est possible et courant, mais un swap très sollicité use le disque. Modéré, c'est sans souci.

Sur quels environnements ?

• VPS / serveurs Linux (bare-metal ou cloud) : cas idéal, on ajoute un swapfile en quelques commandes.
• Conteneurs Docker : le conteneur partage le swap de l'hôte ; on ne « crée » pas de swap dans l'image, on le configure sur la machine hôte (et on peut plafonner via --memory-swap).
• Kubernetes : historiquement le swap était désactivé sur les nœuds ; il est supporté récemment mais reste à activer explicitement au niveau du nœud. On raisonne surtout en requests/limits.
• Offres managées (App Platform, Lambda, Cloud Run…) : pas d'accès à l'OS, donc pas de swap à la main — on choisit une taille d'instance adaptée.

Cas réel : un pipeline GitLab CI/CD qui plante par manque de RAM

Prenons une infrastructure modeste, très répandue chez les petites équipes.

[ Développeur ] --git push--> [ GitLab.com (SaaS) ]
                                   ^
                (le runner interroge GitLab en HTTPS, long polling)
                                   |
            [ VPS OVH — 2 vCPU / 4 Go RAM / SSD ]
            ├─ GitLab Runner (exécute les jobs du pipeline)
            ├─ Backend Java (Spring Boot)
            ├─ MongoDB
            └─ Front Angular (rendu SSR, Node)

Comment communiquent les acteurs

Le code vit sur GitLab.com. Sur le VPS tourne un GitLab Runner : ce n'est pas GitLab qui « pousse » vers le serveur, c'est le runner qui interroge régulièrement GitLab en HTTPS (« tu as un job pour moi ? »). Quand un git push déclenche un pipeline, le runner récupère le job, l'exécute localement (par ex. mvn verify puis npm run build), puis renvoie les logs et les artefacts à GitLab. Tout se passe donc sur le VPS, avec les ressources du VPS.

Le problème : la RAM part en fumée

Un build n'est pas léger. La JVM de Maven, les tests, puis le build Angular (esbuild/Node) réclament chacun plusieurs centaines de Mo à plus d'un Go. Ajoutez le backend, MongoDB et le SSR qui tournent déjà sur la même machine : les 4 Go sont vite saturés. Sans swap, dès que la demande dépasse la RAM disponible, l'OOM killer tue le processus le plus gourmand.

Symptômes typiques : job qui s'arrête net avec exit code 137, message Killed dans les logs Maven/Node, échecs intermittents (ça passe quand la machine est peu chargée, ça casse quand backend + Mongo consomment au même moment). Effet de bord : pendant le build, l'appli elle-même rame ou renvoie des 504.

La correction : ajouter un swap

On donne au noyau une marge sur disque pour absorber les pics du build au lieu de tuer un process. Sur le VPS (Ubuntu/Debian) :

# 1. Créer un fichier d'échange de 4 Go
sudo fallocate -l 4G /swapfile        # à défaut : sudo dd if=/dev/zero of=/swapfile bs=1M count=4096
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# 2. Vérifier qu'il est actif
free -h
swapon --show

# 3. Le rendre permanent (persister après reboot)
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

# 4. Garder le swap en dernier recours (données chaudes en RAM)
sudo sysctl vm.swappiness=10
echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf

Après cela, le pic mémoire du build est absorbé par le swap : le job ralentit légèrement pendant les quelques secondes de tension mais ne se fait plus tuer. Le pipeline redevient stable.

Mais le swap n'est qu'un pansement — à combiner avec

• Limiter la mémoire des builds : ex. MAVEN_OPTS="-Xmx1g", NODE_OPTIONS="--max-old-space-size=1536", éviter les jobs parallèles trop gourmands.
• Isoler le runner : idéalement, exécuter les pipelines sur une autre machine que celle qui héberge la prod, pour ne pas se disputer la RAM.
• Surveiller : free -h, vmstat 1, ou un dashboard, pour repérer un swap constamment plein (signe qu'il faut vraiment plus de RAM).
• Dimensionner : si le swap est sollicité en permanence, la vraie réponse est d'ajouter de la RAM ou de séparer les services.

En résumé

Le swap est une extension sur disque de la mémoire : plus lente, mais qui évite qu'un pic ponctuel ne fasse tuer un processus par l'OOM killer. C'est précieux sur un petit VPS qui héberge à la fois l'application et un runner CI/CD, où un build Maven + Angular peut saturer les 4 Go et faire échouer le pipeline (exit 137). Quelques commandes suffisent à créer un swapfile et à stabiliser les builds — à condition de le voir comme un filet de sécurité, complété par des limites mémoire, de la supervision, et, à terme, le bon dimensionnement de la machine.

Sources et références

• Linux Kernel — Memory Management (concepts)
• Ubuntu — Swap FAQ
• GitLab Runner — documentation officielle