MySQL rame. free -h : 512 Mo swap used, RAM « pleine ». L'équipe double le swap de 2 à 8 Go — la lenteur empire. Le vrai problème : requête sans index + buffer pool trop petit, pas l'absence de swap.
Le swap n'est ni toujours mal ni toujours bien : contexte et métriques.
Lire free et vmstat
available plus fiable que free cache line. vmstat 1 : si si bi/s swap in/out constant en charge → RAM insuffisante.
Distinguer swap used vs swap activity.
Rôles du swap
Filet : évite OOM killer sur pic court.
Symptôme : working set > RAM sustained.
Mauvaise idée : compenser RAM sous-dimensionnée cheap VPS indéfiniment.
Par workload
| Workload | Recommandation |
|---|---|
| PostgreSQL/MySQL | RAM first, swap minimal activity |
| Web PHP stateless | swap OK petit, watch OOM |
| Redis | swap quasi inutile, désactiver ou swappiness 1 |
| Batch nuit | swap peut lisser pics |
Alignez avec hébergeur : certains VPS sans swap par design.
Tuning
swappiness=10 /etc/sysctl.d. SSD swap mieux que HDD mais latence reste ms vs µs RAM.
zram on 1–2 GB VPS si kernel récent.
Décision upgrade
Si swapin/swapout > 0 sustained + latency SLO broken → upgrade RAM ou shard service. Changer swappiness seul = aspirin.
Matrice décision
| Signal | Action |
|---|---|
| swap used, swapin/out ~0 | monitor |
| swapin/out sustained + latency | upgrade RAM |
| OOM kills | RAM + app limit |
| Redis swap | fix immediately |
| Batch nightly swap OK | document expected |
Revoyez après changement instance type cloud — RAM/swap ratio change.
Alerting
Alert si swap used >50% et swapin rate >0 sustained 5min — pas alert swap used alone.
Dashboard : RAM available + swap activity same panel.
Capacity plan : RAM upgrade trigger défini (ex. swapin >10/s 15min).
Kubernetes node swap policy : certains clusters forbid — plan memory requests/limits avant deploy Java heap gourmand.
JVM containers sans limit memory + swap host = latence GC imprévisible.
Containers et swap
Docker sans limit memory : container peut trigger swap host — définissez mem_limit.
Kubernetes : swap off par défaut many clusters — OOMKill pod vs host swap policy explicit.
Monitoring : alert si swap IO wait correlate avec latency API — pas seulement swap used metric.
Synthèse opérationnelle
Swap utilisé n'est pas alerte ; swap actif sous charge l'est. DB production : RAM d'abord. Petits VPS : un peu swap évite OOM brutal. Mesurez vmstat, pas seulement free.
Kubernetes et Redis : éviter swap host pour workloads latency-sensitive.
Lecture dashboard
Paneau 1 : RAM available trend 7j. Paneau 2 : swap in/out rate. Paneau 3 : app p95 latency overlay. Corrélation swapin + latency = ticket RAM upgrade chiffré.
Documentation runbook : quand ignorer swap used statique, quand pager on-call.
Suivi opérationnel
Document baseline swap post-incident — comparaison future. Alert swapin correlé latency. OOM killer log review after swap spike — which process victim. Documentez les écarts entre promesse hébergeur et mesure terrain dans la revue trimestrielle.
Poursuite trimestrielle
Document baseline swap post-incident — comparaison future. Alert swapin correlé latency. OOM killer log review after swap spike — which process victim. Documentez les écarts entre promesse hébergeur et mesure terrain dans la revue trimestrielle.
Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.
Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.
Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.
Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.
Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.
Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.
Matrice swap
| Signal | Action |
|---|---|
| swap used, swapin ~0 | monitor |
| swapin + latency | RAM upgrade |
| Redis swap | fix now |
PaaS : OOM seulement visible — dimensionnez RAM.
Décider et avancer sans angle mort
- Corréler swapin/out et latence app — swap utilisé sans activité = monitor ; swapin soutenu = ticket RAM.
- Dashboard trois panneaux — RAM available, swap I/O, p95 latence overlay.
- Redis et bases jamais en swap — fix immédiat si détecté.
- Documenter batch nocturne acceptable — swap prévisible vs fuite mémoire.
- Revoir après changement instance cloud — ratio RAM/swap change avec le type.
Upgrade RAM : chiffres à la main via le comparateur et fiches annuaire.
Questions fréquentes
Swap 100 % utilisé = urgence ?
Urgence si latence explose et majorité RAM active en swap (si column available bas). Peut être bénin si pages froides inactive.
swappiness 60 ou 10 ?
10–20 sur serveurs prod DB/cache pour éviter swap agressif. 60 défaut desktop-oriented.
Faut-il désactiver swap ?
Rarement sur petit VPS — un peu de swap évite OOM kill brutal. DB critique : plutôt plus de RAM que swap zero.
zram utile ?
Sur petits VPS RAM serrée, zram compresse en RAM — mieux que disk swap lent, pas substitut RAM réelle pour gros working set.
Regardez vmstat avant d'acheter du swap cloud — parfois c'est 4 Go de RAM qui manquent, pas 4 Go de swap.