Ubuntu 24.04 : Swap sur SSD — le faire en sécurité (et quand il ne faut pas) (cas n°50)

Ce qu’est le swap (et ce qu’il n’est pas)

Le swap est une mémoire virtuelle basée sur disque. C’est une soupape de sécurité : quand la RAM est tendue, le noyau peut évincer des pages froides hors de la RAM,
libérant de l’espace pour les pages chaudes. Bien utilisé, le swap transforme « processus tué » en « processus ralenti ».
Mal utilisé, le swap transforme « lent » en « non réactif ».

Sur Ubuntu 24.04, vous aurez généralement un fichier de swap à /swap.img créé par l’installateur, géré via systemd.
Vous pouvez aussi avoir zram (swap compressé en RAM) selon la saveur et la configuration. Chacun a des modes de défaillance différents.

Le modèle mental dont vous avez besoin

• Swap n’est pas de la RAM supplémentaire. C’est une solution de secours avec une latence très différente.
• Swap n’est pas seulement pour les urgences. Il peut être utilisé de manière proactive pour garder un comportement de cache efficace, surtout sur des charges mixtes.
• Swap n’est pas la cause de votre fuite mémoire. C’est juste l’endroit où la fuite finit par mourir lentement.

Le SSD change la donne parce que les E/S de swap deviennent « moins terribles », pas « rapides ».
Le NVMe peut produire des IOPS impressionnants, mais le swapping implique souvent de petites lectures aléatoires lors de défauts de page — la latence compte, l’ordonnancement compte,
et les limites de cgroup comptent. Un SSD rapide peut toujours être la chose la plus lente de la salle.

Une citation que les opérationnels intègrent tôt :
« L’espoir n’est pas une stratégie. » — General Gordon R. Sullivan

Si votre plan est « activer le swap et espérer », vous obtiendrez le swap que vous méritez.

Faits et historique importants

1. Le swap est antérieur à Linux. Le paging et les stratégies de swap étaient au cœur des systèmes UNIX de partage de temps bien avant que les PC grand public n’aient assez de RAM.
2. Linux utilise le swap plus intelligemment qu’on ne le suppose. Il peut évincer la mémoire anonyme tout en gardant le cache de fichiers chaud, selon la pression et les réglages.
3. La peur « le swap abîme les SSD » vient des premiers flash. Les premiers SSD grand public avaient des contrôleurs et une endurance plus faibles ; les NVMe modernes sont bien plus robustes.
4. Ubuntu a migré vers les swapfiles il y a des années. Les partitions de swap restent valides, mais les fichiers de swap sont plus faciles à redimensionner et déployer à l’échelle.
5. L’hibernation est un cas spécial du swap. L’hibernation requiert une zone de swap suffisamment grande pour contenir le contenu de la RAM, et les fichiers de swap demandent une configuration de démarrage supplémentaire.
6. Les cgroups ont changé le sens du « out of memory ». Un conteneur peut provoquer un OOM kill alors que l’hôte a de la RAM libre, et le swap peut être désactivé au niveau du cgroup.
7. zram est devenu populaire parce que le CPU est devenu bon marché. Compresser des pages froides en RAM peut battre l’accès disque, surtout sur les portables et petites VM.
8. NVMe a rendu le swap « possible » sur des systèmes à haut débit. Cela ne rend pas le swap rapide, mais cela peut l’empêcher d’être catastrophiquement lent comme les disques rotatifs.

Blague #1 : Le swap, c’est comme un tapis roulant d’aéroport — utile si vous marchez déjà, embarrassant si vous vous en servez pour déplacer un piano.

Faut-il mettre le swap sur SSD ?

Mon défaut d’opinion

Sur Ubuntu 24.04 avec un SSD, vous devriez en général garder un peu de swap activé — sauf si vous avez une raison précise de ne pas le faire.
« Un peu » signifie quelques gigaoctets pour la plupart des serveurs, et suffisamment pour l’hibernation si vous utilisez réellement l’hibernation.

Le swap sur SSD est utile pour

• Prévenir les OOM kills soudains sur des charges en rafales (compilations de paquets, indexation de logs, warmups JVM).
• Garder le système stable sous pression mémoire afin que vous puissiez vous connecter, inspecter et corriger le problème réel.
• Réduire le risque extrême lorsque vous exécutez de nombreux services et qu’un seul devient défaillant.
• La sanity de l’overcommit sur des hôtes qui utilisent l’overcommit mémoire de manière responsable (et qui ont de la supervision).

Le swap sur SSD est mauvais pour

• Services sensibles à la latence, quasi temps réel où des défauts de page occasionnels sont inacceptables.
• Systèmes déjà limités par les E/S (disques de base de données occupés, files NVMe saturées, nœuds de stockage effectuant un vrai travail).
• Les cultures « on refuse de dimensionner la RAM correctement ». Le swap devient une béquille, puis une facture.

La question clé

Essayez-vous de survivre à une mauvaise journée, ou essayez-vous d’économiser de l’argent en sous-dimensionnant la mémoire de façon permanente ?
Le swap est utile pour la première situation et terrible pour la seconde.

Guide de diagnostic rapide

Quand un hôte paraît « gelé », vous n’avez pas le temps pour la philosophie. Il vous faut un chemin court vers le goulet d’étranglement.
Voici l’ordre qui fonctionne souvent en production.

1) Confirmer que vous swappez (et à quel point)

• Si l’usage du swap est proche de zéro, ce n’est pas un incident de swap. Passez au CPU, I/O ou verrous.
• Si l’usage du swap est élevé et en croissance, vous êtes en pression mémoire et approchez du thrash.
• Si l’usage du swap est stable mais que la machine est lente, vous pourriez avoir des tempêtes d’échange entrant (page faults) plutôt qu’un swap continu.

2) Décider si le goulet est le disque I/O ou le CPU

• Un fort wa (I/O wait) et de hauts taux d’échange entrant/sortant indiquent généralement que le chemin de stockage est le limiteur.
• Un faible I/O wait mais un CPU fortement utilisé avec compression zram peut signifier que vous payez en CPU pour éviter les E/S disque.

3) Identifier la classe de processus qui cause la pression

• Cherchez un processus devenu fou (fuite mémoire) versus de nombreux processus normaux combinés (RAM sous-dimensionnée).
• Sur les serveurs, vérifiez d’abord les limites de cgroup ; l’hôte peut être correct.

4) Agir : stabiliser, puis réparer

• Si c’est du thrashing : réduire la charge, arrêter le coupable, ou ajouter temporairement du swap/zram seulement si cela restaure le contrôle.
• Si c’est chronique : ajouter de la RAM ou réduire le working set. Régler la swappiness n’est pas un substitut à la planification de capacité.

Tâches pratiques (commandes, sorties, décisions)

Voici les vérifications et interventions exactes que j’exécute sur des hôtes Ubuntu 24.04. Chaque tâche inclut un extrait de sortie réaliste,
ce que cela signifie, et la décision à prendre.

Task 1: See what swap exists and whether it’s active

cr0x@server:~$ swapon --show --bytes
NAME       TYPE SIZE        USED PRIO
/swap.img  file 8589934592  0    -2

Signification : Vous avez un swapfile de 8 GiB et il est activé, actuellement inutilisé.

Décision : Si vous dépannez une lenteur et que USED est proche de SIZE, vous êtes probablement en pression mémoire. Si USED est 0, le swap n’est pas le coupable.

Task 2: Quick RAM + swap status snapshot

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        25Gi       1.2Gi       1.0Gi       5.0Gi       3.0Gi
Swap:          8.0Gi       6.5Gi       1.5Gi

Signification : Le swap est fortement utilisé et la RAM disponible est faible. C’est une posture « lent maintenant, pire plus tard ».

Décision : Vérifiez si le système échange activement (Task 3). S’il n’échange pas activement, il peut s’agir d’un usage historique du swap qui n’a pas été récupéré.

Task 3: Detect active swapping vs old swapped-out pages

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0 6815744  93248  90112 2840000 120  240   300   600  800 1200 12  5 70 13  0
 3  1 6897664  84520  89400 2815000 800 1200  2100  3300 1400 2100 10  6 55 29  0
 1  1 7012352  70212  88000 2780000 600  900  1600  2400 1300 1900  9  5 58 28  0
 1  0 7012352  76000  88500 2779000   0    0   200   300  900 1400  8  4 84  4  0
 1  0 7012352  77000  88500 2778000   0    0   150   250  850 1300  7  4 85  4  0

Signification : Les pics de si/so (swap-in/swap-out) montrent un thrash actif pendant les premières secondes, puis se calment.

Décision : Si les pics corrèlent avec la latence, vous devez réduire la pression mémoire ou la contention I/O. Si c’est constamment élevé, vous êtes en thrash soutenu.

Task 4: Check kernel swappiness and cache pressure knobs

cr0x@server:~$ sysctl vm.swappiness vm.vfs_cache_pressure
vm.swappiness = 60
vm.vfs_cache_pressure = 100

Signification : Comportement par défaut : le swap est autorisé à mesure que la pression augmente.

Décision : Pour de nombreux serveurs, envisagez vm.swappiness=10 ou 20 si vous voulez privilégier fortement la conservation des pages anonymes en RAM — mais seulement après avoir confirmé que vous ne masquez pas un problème de RAM sous-dimensionnée.

Task 5: See if the system is OOM-killing

cr0x@server:~$ journalctl -k -g "Out of memory" -n 5
Dec 30 09:12:21 server kernel: Out of memory: Killed process 21877 (java) total-vm:18233400kB, anon-rss:12984320kB, file-rss:12288kB, shmem-rss:0kB, UID:1001 pgtables:36244kB oom_score_adj:0

Signification : Vous n’échangez pas seulement ; vous atteignez encore l’OOM. Le swap n’est pas assez grand ou la demande mémoire augmente plus vite que le système ne peut récupérer.

Décision : Corrigez le service fautif ou augmentez la mémoire. Augmenter le swap peut acheter du temps, mais si le working set dépasse réellement la RAM, les performances souffriront.

Task 6: Identify top memory consumers quickly

cr0x@server:~$ ps -eo pid,comm,rss,vsz,pmem --sort=-rss | head
  PID COMMAND           RSS      VSZ %MEM
21877 java          12984320 18233400 41.2
 8421 postgres       2845120  5120000  9.0
 3112 node            980000  1600000  3.1
 1991 snapd            210000   980000  0.6

Signification : Une JVM monopolise la mémoire résidente. C’est probablement la source de la pression.

Décision : Validez si c’est attendu (cache) ou une fuite/croissance. Pour Java, inspectez les réglages du heap ; pour tout le reste, vérifiez les déploiements récents.

Task 7: Check per-process swap usage (who’s actually swapped out)

cr0x@server:~$ sudo smem -rs swap | head
  PID User     Command                         Swap      USS      PSS      RSS
 8421 postgres /usr/lib/postgresql/16/bin/...  2200M    850M    910M   1200M
 3112 www-data node /srv/app/server.js         1100M    420M    480M    600M
 1991 root     /usr/lib/snapd/snapd             210M     80M     90M    140M

Signification : Postgres et node ont de larges empreintes échangées. Cela implique généralement qu’ils étaient inactifs à un moment ou que le noyau les a choisis comme candidats à l’éviction.

Décision : Si ces processus sont critiques en latence, envisagez d’ajuster la swappiness, les limites mémoire, ou assurez-vous d’avoir assez de RAM. S’ils sont batch, cela peut être acceptable.

Task 8: Measure real storage pressure and queueing

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.0-41-generic (server) 	12/30/2025 	_x86_64_	(8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.12    0.00    4.50   28.20    0.00   57.18

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await wareq-sz aqu-sz  %util
nvme0n1         980.0   18000.0     0.0   0.00    7.20    18.37   420.0   12000.0   12.40    28.57   8.10  98.50

Signification : Le NVMe est presque saturé (%util ~ 98%) et les temps d’attente augmentent. Si le swap est actif, il concurrence tout le reste.

Décision : Si votre swap est sur le même périphérique que votre base de données, c’est un combat au couteau dans une cabine téléphonique. Envisagez de déplacer le swap vers un périphérique moins sollicité, ou corrigez le dimensionnement mémoire.

Task 9: Confirm whether swap is a file and where it lives

cr0x@server:~$ ls -lh /swap.img
-rw------- 1 root root 8.0G Dec 30 08:52 /swap.img

Signification : C’est un fichier de swap sur le système de fichiers root.

Décision : Assurez-vous que le système de fichiers prend en charge les swapfiles en toute sécurité (ext4 le fait ; btrfs nécessite une manipulation spéciale). Si root est sur chiffrement/LVM, ça va, mais comprenez les implications pour l’hibernation.

Task 10: Verify filesystem type (swapfile safety check)

cr0x@server:~$ findmnt -no FSTYPE /
ext4

Signification : ext4 est compatible avec les swapfiles.

Décision : Procédez normalement. Si vous voyez btrfs, arrêtez-vous et suivez les règles spécifiques aux swapfiles btrfs (pas de CoW, extents contigus).

Task 11: Check TRIM/discard status (SSD housekeeping)

cr0x@server:~$ systemctl status fstrim.timer --no-pager
● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; preset: enabled)
     Active: active (waiting) since Mon 2025-12-29 10:00:00 UTC; 23h ago
    Trigger: Mon 2026-01-05 10:00:00 UTC; 5 days left

Signification : Le TRIM hebdomadaire est activé. Bien : cela aide à la constance des performances SSD dans le temps.

Décision : Gardez-le. N’ajoutez pas l’option de montage discard en continu juste pour se sentir productif ; le TRIM planifié est généralement la bonne solution ennuyeuse.

Task 12: See memory pressure signals (PSI) and act like an adult

cr0x@server:~$ cat /proc/pressure/memory
some avg10=0.85 avg60=0.40 avg300=0.15 total=23840219
full avg10=0.20 avg60=0.08 avg300=0.02 total=4022191

Signification : Le système est régulièrement bloqué sur la récupération mémoire (some) et occasionnellement complètement bloqué (full).

Décision : Ce n’est pas théorique. Vous payez une latence réelle. Réduisez le working set, ajoutez de la mémoire, ou ajoutez un swap/zram rapide comme mitigation pendant que vous corrigez la cause racine.

Task 13: Check whether zram is enabled (and how big)

cr0x@server:~$ swapon --show
NAME       TYPE      SIZE   USED PRIO
/swap.img  file      8G     2.1G   -2
/dev/zram0 partition 4G     1.3G  100

Signification : zram est présent avec une priorité plus élevée (100). Le noyau utilisera zram avant le swapfile SSD.

Décision : C’est souvent une bonne configuration sur les systèmes polyvalents. Si le CPU est surchargé et que le coût de compression nuit, envisagez d’ajuster ou de désactiver zram — mais seulement avec des preuves.

Task 14: Validate swap priority and adjust intentionally

cr0x@server:~$ cat /proc/swaps
Filename				Type		Size		Used		Priority
/dev/zram0                               partition	4194300	1365000		100
/swap.img                                file		8388604	2200000		-2

Signification : zram sera favorisé, le swapfile est en secours.

Décision : Bon choix par défaut : garder le swap SSD comme « deuxième ligne de défense ». Si vous comptez sur le swap SSD pour l’hibernation, assurez-vous que priorités et tailles ne bloquent pas ce plan.

Task 15: Temporarily disable swap to prove it’s the bottleneck (carefully)

cr0x@server:~$ sudo swapoff -a
swapoff: /swap.img: swapoff failed: Cannot allocate memory

Signification : Vous n’avez pas assez de RAM libre pour rapatrier les pages échangées. Le swap retient actuellement la construction.

Décision : Ne forcez pas cela. Réduisez d’abord l’utilisation mémoire (arrêtez des services, réduisez la charge) ou ajoutez de la RAM. Désactiver le swap dans cet état fera de l’OOM killer votre nouveau SRE.

Task 16: Check NVMe health and endurance signals (sanity, not superstition)

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | egrep -i "data units written|percentage used|critical_warning"
critical_warning                    : 0x00
percentage_used                     : 3%
data_units_written                  : 1,234,567 [632 TB]

Signification : L’état du disque semble correct ; l’utilisation d’endurance est faible. L’I/O de swap n’est pas automatiquement une sentence de mort.

Décision : Concentrez-vous sur la performance et la stabilité. Ne bannissez pas le swap sur la base d’un folklore SSD obsolète ; validez avec les métriques de santé et d’écriture.

Schémas d’installation sûrs sur Ubuntu 24.04

Schéma A : Conserver le swapfile par défaut, mais ajuster le comportement

Pour la plupart des systèmes, l’approche la plus simple et sûre est : conserver /swap.img, confirmer qu’il est sur ext4/xfs,
s’assurer que le TRIM est actif, et régler la swappiness de façon conservatrice.

Définir la swappiness de façon persistante

cr0x@server:~$ echo 'vm.swappiness=20' | sudo tee /etc/sysctl.d/99-swappiness.conf
vm.swappiness=20

cr0x@server:~$ sudo sysctl --system | tail -n 3
* Applying /etc/sysctl.d/99-swappiness.conf ...
vm.swappiness = 20

Signification : Le noyau fera plus d’efforts pour garder la mémoire anonyme en RAM et récupérer d’abord le cache.

Décision : Utilisez 10–30 pour de nombreux workloads serveurs. Évitez de mettre 0 comme « pas de swap » ; ce n’est pas la même chose et peut conduire à des comportements de récupération surprenants sous pression.

Schéma B : Utiliser zram en première ligne, swap SSD en seconde

Si vous exécutez des workloads mixtes et voulez une dégradation gracieuse, zram vous donne du temps sans marteler immédiatement le SSD.
Sur les CPU modernes, c’est souvent un gain net. Sur les CPU modestes ou les machines déjà liées au CPU, cela peut être contre-productif.

Ubuntu peut déjà fournir zram via des paquets et des presets selon votre installation. Si vous l’activez vous-même, gardez-le modéré.
Sur-allouer zram est la manière de transformer « compression » en « pourquoi le ventilateur CPU hurle dans une baie de datacenter ».

Schéma C : Partition swap dédiée sur SSD (rarement nécessaire)

Les partitions de swap sont toujours valables. Elles peuvent être plus simples pour l’hibernation et éviter certains cas limites du système de fichiers.
Mais pour la plupart des flottes de production, les swapfiles sont plus faciles à redimensionner et gérer avec des outils de configuration.

Redimensionner un swapfile en toute sécurité

La séquence sûre est : désactiver le swapfile, redimensionner, définir les permissions, formater la signature swap, réactiver, valider.
La séquence dangereuse est « tronquer un swapfile actif et prier ».

cr0x@server:~$ sudo swapon --show
NAME      TYPE SIZE USED PRIO
/swap.img file 8G   0B   -2

cr0x@server:~$ sudo swapoff /swap.img

cr0x@server:~$ sudo fallocate -l 16G /swap.img

cr0x@server:~$ sudo chmod 600 /swap.img

cr0x@server:~$ sudo mkswap /swap.img
Setting up swapspace version 1, size = 16 GiB (17179865088 bytes)
no label, UUID=2b4b2b0a-3baf-4c5d-9b7e-8e8d7d0f5b43

cr0x@server:~$ sudo swapon /swap.img

cr0x@server:~$ swapon --show
NAME      TYPE SIZE  USED PRIO
/swap.img file 16G   0B   -2

Signification : Le swap est redimensionné et actif.

Décision : Choisissez une taille qui correspond à votre objectif : survivre à un crash et garder le contrôle opérationnel, pas remplacer définitivement la RAM.

Hygiène spécifique au SSD qui compte vraiment

• Évitez les périphériques très sollicités : ne placez pas le swap sur le même NVMe fortement utilisé que votre base de données si vous pouvez l’éviter.
• Gardez le TRIM actif : un fstrim.timer hebdomadaire suffit pour la plupart.
• Ne vous obsédez pas sur l’usure sans preuve : vérifiez les statistiques SMART/NVMe et les hypothèses d’écriture avant de déclarer le swap « dangereux ».
• Utilisez les priorités : si vous avez plusieurs backends de swap (zram + swapfile SSD), définissez les priorités intentionnellement.

Quand ne pas utiliser le swap sur SSD

Il existe des cas réels où le swap sur SSD est la mauvaise décision. Pas parce que les SSD sont fragiles,
mais parce que l’I/O de swap au mauvais endroit devient un amplificateur d’incident à l’échelle du système.

1) Nœuds de stockage et serveurs de base de données avec disques saturés

Si votre NVMe est déjà occupé à servir des lectures/écritures de base de données ou la réplication de stockage, le swap concurrence dans les mêmes files.
Sous pression mémoire, les pics de latence provoquent plus de timeouts, plus de retries, plus de charge, plus de swap. Vous obtenez la spirale.

Dans ces systèmes, la réponse plus correcte est : dimensionner la RAM pour le working set, définir des limites mémoire, et garder le swap minimal — parfois même désactivé — si vous pouvez garantir de ne pas en avoir besoin.
Cette dernière clause est là où la plupart des équipes se mentent à elles-mêmes.

2) Services ultra-faibles en latence

Si vous exécutez des services avec des SLOs de latence stricts et des patterns d’accès en rafales, les défauts de page dus au swap peuvent violer les SLOs d’une manière difficile à reproduire.
Vos métriques afficheront « un pic bizarre » qui gâche la journée.

3) Attentes mal configurées pour l’hibernation

Si vous « avez besoin d’hibernation » mais ne configurez pas le resume pour les swapfiles, vous finirez par tester l’hibernation au pire moment.
Et la machine ne reviendra pas.

4) Root chiffré avec contraintes de démarrage complexe (cas limites)

Le swap sur root chiffré est acceptable pour le swapping normal. Le resume d’hibernation est là où la complexité apparaît : initramfs doit trouver la zone de swap tôt.
Si vous ne voulez pas gérer cette complexité, ne prétendez pas avoir besoin d’hibernation.

Blague #2 : Rien ne dit « vendredi après-midi » comme découvrir que votre « tweak temporaire de swap » a été intégré dans l’image dorée il y a six mois.

Erreurs courantes : symptôme → cause → réparation

1) Symptom: host is “up” but SSH takes 20–60 seconds

Cause racine : thrash de swap (forte latence des défauts de page) et le CPU est bloqué en reclaim ; les shells interactifs subissent des défauts de page constants.

Réparation : Confirmez avec vmstat (si/so) et PSI. Réduisez la charge immédiatement (arrêtez le coupable), puis ajoutez de la RAM ou limitez l’usage mémoire. Envisagez zram comme mitigation.

2) Symptom: swap is full, but si/so is near zero

Cause racine : usage historique du swap ; les pages échangées sont froides et ne sont pas référencées. Ce n’est pas un incident actif en soi.

Réparation : Si les performances vont bien, ne faites rien. Si vous voulez récupérer le swap, vous pouvez swapoff/swapon pendant une fenêtre de maintenance seulement s’il y a suffisamment de RAM libre.

3) Symptom: OOM kills happen even with plenty of swap

Cause racine : limites mémoire de cgroup (conteneurs), ou rafales d’allocation rapides où la récupération ne suit pas, ou politiques oom_score_adj qui ciblent le mauvais processus.

Réparation : Vérifiez les limites de cgroup, les réglages du runtime de conteneur pour le swap, et les logs du noyau. Corrigez le consommateur mémoire ou augmentez la limite ; n’augmentez pas simplement le swap.

4) Symptom: NVMe %util pinned at ~100% and everything slows

Cause racine : I/O de swap en concurrence avec la charge principale, souvent sur le même périphérique.

Réparation : Déplacez le swap vers un périphérique moins sollicité ou réduisez le swapping en ajoutant de la RAM / diminuant le working set. Si possible, isolez les classes d’I/O avec les cgroups et les contrôleurs I/O, mais n’attendez pas de miracles.

5) Symptom: enabling zram makes the system slower

Cause racine : workload lié au CPU ; la surcharge de compression vole des cycles à l’application. Ou zram est surdimensionné et provoque du churn.

Réparation : Mesurez le temps CPU et la charge. Réduisez la taille de zram ou désactivez zram sur cette classe d’hôtes ; utilisez le swap SSD en secours si approprié.

6) Symptom: swapfile exists but isn’t used at all

Cause racine : le swap est désactivé, entrée /etc/fstab incorrecte, ou unité systemd non active.

Réparation : Exécutez swapon --show. Assurez-vous que /etc/fstab inclut le swapfile et que les permissions sont correctes (0600), puis activez le swap.

7) Symptom: hibernate fails or resumes into a reboot

Cause racine : offset de resume non configuré pour le swapfile, swap pas assez grand, ou boot précoce ne peut pas accéder au périphérique de backing swap.

Réparation : Si vous devez hiberner, utilisez une partition de swap ou configurez correctement le resume pour le swapfile et reconstruisez initramfs. Sinon, arrêtez de prétendre que l’hibernation est une exigence.

Listes de vérification / plan étape par étape

Checklist A: Decide whether swap on SSD is acceptable for this host

1. Le workload est-il critique en latence avec des SLOs stricts sur les queues extrêmes ? Si oui, gardez le swap minimal et concentrez-vous sur le dimensionnement RAM et les limites.
2. Le SSD est-il fortement utilisé pour les I/O du workload principal ? Si oui, le swap concurrence et peut amplifier les incidents.
3. Avez-vous besoin de l’hibernation ? Si oui, planifiez la taille du swap et la configuration du resume intentionnellement.
4. Exécutez-vous des conteneurs avec des limites mémoire strictes ? Si oui, validez les réglages de swap des cgroups ; le swap hôte ne sauvera pas un conteneur configuré pour ne pas l’utiliser.
5. Avez-vous la surveillance de la pression mémoire (PSI), de l’activité swap et de la latence disque ? Si non, vous volez sans instruments installés.

Checklist B: Deploy a safe swapfile on Ubuntu 24.04 (ext4 root)

1. Confirmez le type de système de fichiers : findmnt -no FSTYPE / doit être ext4/xfs.
2. Vérifiez le swap actuel : swapon --show.
3. Si redimensionnement, assurez-vous que l’usage du swap est faible et que la RAM a de la marge ; puis swapoff le fichier.
4. Créer/redimensionner avec fallocate ou dd (fallocate est OK sur ext4).
5. Définissez les permissions : chmod 600.
6. Formatez le swap : mkswap.
7. Activez : swapon.
8. Persistez dans /etc/fstab (ou reposez-vous sur la configuration Ubuntu existante si présente).
9. Validez avec free -h et swapon --show.

Checklist C: Stabilize a thrashing host (get control back)

1. Confirmez le thrash : vmstat 1 et cat /proc/pressure/memory.
2. Identifiez le coupable : ps/smem, puis métriques applicatives.
3. Réduisez la charge : arrêtez le worker non essentiel, mettez en pause les jobs batch, réduisez la concurrence.
4. Libérez la mémoire en sécurité : redémarrez le coupable s’il fuit, ou videz les caches seulement si vous comprenez l’impact (généralement vous ne devriez pas).
5. Ensuite seulement, envisagez de changer la taille du swap/zram comme mitigation à court terme.
6. Après stabilité : corrigez la cause racine (fuite mémoire, mauvaises limites, sous-dimensionnement, voisin bruyant).

Trois mini-histoires d’entreprise (anonymisées, plausibles, techniquement douloureuses)

Incident causé par une mauvaise hypothèse : « Le swap est désactivé dans les conteneurs, donc l’hôte n’a pas d’importance. »

Une équipe a exécuté un ensemble de services Java et Node sur des hôtes Ubuntu sous un runtime de conteneurs. Ils croyaient que le swap était « une préoccupation de conteneur »,
et que désactiver le swap au niveau de l’hôte était inoffensif parce que « les conteneurs ont des limites mémoire de toute façon ».
Ils ont désactivé le swap dans tout un environnement pour « rendre les performances plus prévisibles ».

Le premier signe de problème n’a pas été la performance. Ce fut la disponibilité. Des pics périodiques — vagues de déploiement, warmups de cache, quelques jobs batch clients —
ont commencé à causer des OOM kills. Pas des redémarrages gracieux, non. Le noyau tuait le plus gros processus possible dans le cgroup à ce moment-là,
qui était parfois un sidecar de logging et parfois le processus API principal.

La mauvaise hypothèse était subtile : les limites de mémoire des cgroups étaient définies, mais les rafales étaient légitimes.
Sans swap, il n’y avait pas de tampon pour absorber les pics transitoires. L’équipe avait réglé les heaps JVM près des limites et supposé que le reste de la mémoire
(allocations natives, mmap, overhead JIT) se comporterait.

Une fois le swap réintroduit — modestement, avec une swappiness conservatrice — les événements OOM ont fortement diminué. Les performances ne sont pas devenues « imprévisibles ».
Elles sont devenues survivables. La vraie correction, plus tard, a été de laisser plus de marge mémoire et de définir des limites de conteneur plus réalistes.
Le swap n’était pas la solution. C’était la ceinture de sécurité.

Optimisation qui a échoué : « Mettre le swap sur le NVMe le plus rapide et augmenter la swappiness pour améliorer le cache. »

Une autre organisation avait des NVMe partout et une culture qui valorisait le tuning intelligent. Quelqu’un a proposé : mettre le swap sur NVMe,
régler la swappiness haute, et laisser le noyau pousser les pages froides pour que le cache de fichiers grandisse. Pendant un temps, cela paraissait bon dans les benchs.

Puis la réalité est arrivée : un hôte à charge mixte exécutant une base de données, une stack de métriques, et quelques jobs batch. Pendant une exécution quotidienne de batch,
la pression mémoire augmente et le noyau commence à swapper. Le NVMe, déjà occupé par les écritures et les compactations de la base de données, atteint la saturation.
La latence explose. Les requêtes de la base de données ralentissent. Les retries augmentent la charge. Le système commence à swapper davantage parce que plus de processus attendent plus longtemps,
gardant la mémoire occupée. Boucle de rétroaction classique.

Le pire : les graphes étaient déroutants. Le CPU n’était pas saturé. Le réseau allait bien. L’équipe regardait les métriques applicatives
pendant que l’hôte mettait tranquillement les E/S en file d’attente comme s’il collectionnait des timbres.

La correction finale était peu sexy : baisser la swappiness, isoler le job batch sur une autre classe de nœud, et arrêter de mettre le swap dans le même périmètre I/O
que la base de données. La leçon n’était pas « le swap est mauvais ». La leçon était « le swap, c’est de l’I/O », et l’I/O est une ressource partagée que vous le reconnaissiez ou non.

Pratique ennuyeuse mais correcte qui a sauvé la journée : « Nous avons gardé petit swap, zram, et des alertes de pression. »

Une équipe plateforme exploitait une flotte de VMs Ubuntu 24.04 avec une RAM modeste. Ils avaient une règle simple :
un petit swap SSD, zram activé à une taille conservatrice, et des alertes sur PSI mémoire et taux d’échange entrant. Pas d’héroïsme. Pas d’arguments « le swap est toujours mauvais ».
Juste des valeurs par défaut avec des garde-fous.

Un jour, une mise à jour d’un agent fournisseur a introduit une fuite mémoire. L’agent n’était pas critique, mais il tournait partout.
Sur plusieurs heures, la pression mémoire a lentement monté. Sur des hôtes sans swap, ce type de fuite tend à produire des OOM soudains et des redémarrages en cascade.

Sur cette flotte, les hôtes ont décliné lentement : le PSI a commencé à monter, les taux d’échange entrant ont augmenté, et l’alerte s’est déclenchée alors que les systèmes étaient encore joignables.
Les ingénieurs se sont connectés, ont vu le coupable, et ont rollbacké le paquet de l’agent.
La « réparation » a été simple parce que l’incident était observable et que les systèmes sont restés interactifs assez longtemps pour agir.

Le swap n’a pas empêché la fuite. La supervision n’a pas empêché la fuite. La combinaison a empêché qu’un mauvais déploiement devienne une panne d’ampleur flotte.
Voilà à quoi ressemble la fiabilité la plupart du temps : ennuyeuse, mesurable, et silencieusement efficace.

FAQ

1) Is swap on SSD safe for the drive?

Généralement oui. Les SSD modernes ont un wear-leveling et une endurance bien supérieurs aux premiers modèles grand public. Vérifiez les métriques SMART NVMe et vos volumes d’écriture.
Si vous swappez constamment, vous avez un problème de capacité, pas un « problème de swap ».

2) How much swap should I use on Ubuntu 24.04?

Pour les serveurs : souvent 2–8 GiB comme tampon de sécurité, davantage si vous avez des pics occasionnels et pouvez tolérer des ralentissements. Pour postes de travail/portables : assez pour lisser les pics,
et suffisamment pour l’hibernation si vous l’utilisez. Si vous avez besoin d’hibernation, dimensionnez le swap à peu près à la RAM (les besoins exacts varient avec la compression et le workload).

3) Swapfile or swap partition?

Le swapfile est plus facile à redimensionner et automatiser. La partition de swap peut être plus simple pour l’hibernation et évite certaines contraintes spécifiques au système de fichiers.
Sur ext4, le swapfile est un bon choix par défaut.

4) Should I set swappiness to 1 or 0?

Pas par réflexe. Des valeurs comme 10–30 sont raisonnables pour de nombreux serveurs afin de privilégier la RAM. Mettre 0 peut se comporter différemment de « presque jamais swapper »
et provoquer des patterns de récupération désagréables sous pression.

5) Why is swap used even when I have “free” RAM?

Parce que « free » n’est pas le seul objectif. Le noyau équilibre mémoire anonyme et cache de fichiers, et peut garder le cache chaud tout en poussant des pages anonymes froides.
Regardez available dans free -h, pas seulement free.

6) Does zram replace SSD swap?

Cela complète le swap. zram est plutôt rapide et évite les E/S disque, mais utilise le CPU et consomme toujours de la RAM (compressée). Le swap SSD est plus lent mais fournit un backing store plus grand.
Un schéma courant est zram priorité haute, swap SSD priorité basse.

7) Can I disable swap entirely?

Oui, mais faites-le seulement si vous avez testé les pics mémoire, si vous avez des limites mémoire correctes, et si vous acceptez que les OOM kills surviennent plus tôt et de façon plus brutale.
Désactiver le swap ne corrige pas les fuites mémoire ou les nœuds sous-dimensionnés. Cela change seulement le mode de défaillance.

8) How do I know if swap is causing my latency?

Recherchez une activité d’échange entrant/sortant active dans vmstat, un PSI mémoire élevé, et la latence/queueing disque dans iostat.
Un fort usage de swap seul n’est pas une preuve ; une forte activité de swap corrélée à des blocages l’est.

9) Will moving swap to a different SSD help?

Ça peut aider si le périphérique actuel est contendu. La performance du swap dépend surtout de la latence sous file d’attente.
Mettre le swap sur le même périphérique occupé que votre base de données peut amplifier les pires moments.

Étapes suivantes que vous pouvez faire aujourd’hui

Si vous exécutez Ubuntu 24.04 sur SSD, la base sensée est : garder un swapfile modeste, s’assurer que le TRIM est activé,
et régler la swappiness seulement après avoir mesuré la véritable pression mémoire. Ajoutez zram si cela aide votre classe d’hôtes, pas parce que c’est tendance.

Faites ces trois choses ensuite :

1. Mesurer : exécutez swapon --show, vmstat 1, iostat -xz 1, et vérifiez /proc/pressure/memory pendant une période de lenteur.
2. Décider : si vous thrashez, corrigez le working set (limites, fuites, capacité). Si vous portez seulement des pages froides, ne réagissez pas excessivement.
3. Renforcer : gardez le swap modeste, fixez une swappiness conservatrice (souvent 10–30 sur les serveurs), et alertez sur la pression mémoire avant que les utilisateurs ne vous alertent.

Le swap sur SSD n’est pas un péché. C’est un outil. Utilisez-le comme tel : avec des mesures, des objectifs clairs, et un plan pour quand il ne suffira pas.