MySQL drags. free -h: 512 MB swap used, RAM "full". Team doubles swap 2→8 GB — gets slower. Real issue: missing index + tiny buffer pool, not lack of swap.
Swap is not always bad or good: context and metrics.
Reading free and vmstat
available beats naive free. vmstat 1: constant swap in/out under load → insufficient RAM.
Distinguish swap used vs swap activity.
Swap roles
Safety net for short spikes.
Symptom of sustained working set > RAM.
Bad idea to compensate cheap undersized VPS forever.
By workload
DB: RAM first. Stateless web: small swap OK. Redis: avoid swap. Batch: swap may smooth peaks.
Tuning
swappiness=10. SSD swap still ms latency. zram on tiny VPS.
Upgrade decision
Sustained swap activity + broken SLO → RAM upgrade or shard. swappiness alone is aspirin.
Decision matrix
| Signal | Action |
|---|---|
| swap used, swapin/out ~0 | monitor |
| sustained swapin/out + latency | upgrade RAM |
| OOM kills | RAM + app limit |
| Redis swap | fix immediately |
| OK nightly batch swap | document expected |
Review after cloud instance type change — RAM/swap ratio shifts.
Alerting
Alert if swap used >50% and swapin rate >0 sustained 5min — not swap used alone.
Dashboard: RAM available + swap activity same panel.
Capacity plan: defined RAM upgrade trigger (e.g. swapin >10/s 15min).
Kubernetes node swap policy: some clusters forbid — plan memory requests/limits before deploying hungry Java heap.
JVM containers without memory limit + host swap = unpredictable GC latency.
Containers and swap
Docker without memory limit: container can trigger host swap — set mem_limit.
Kubernetes: swap off by default many clusters — OOMKill pod vs explicit host swap policy.
Monitoring: alert if swap IO wait correlates with API latency — not swap used metric alone.
Operational summary
Swap used is not an alert; active swap under load is. Prod DB: RAM first. Small VPS: some swap avoids brutal OOM. Measure vmstat, not just free.
Kubernetes and Redis: avoid host swap for latency-sensitive workloads.
Dashboard reading
Panel 1: RAM available 7d trend. Panel 2: swap in/out rate. Panel 3: app p95 latency overlay. Swapin + latency correlation = numbered RAM upgrade ticket.
Runbook documentation: when to ignore static swap used, when to pager on-call.
Managed platforms
PaaS hides swap — you see OOM restart only. Translate platform metrics to RAM sizing decisions anyway.
Java heap Xmx near container limit guarantees pain — leave headroom or accept restart policy.
Monitoring checklist
Alert: swap used >50% AND swapin rate >0 for 5 minutes. Dashboard: RAM available + swap activity + app latency same panel. Document baseline swap used after reboot — some OS preload swap harmless.
Hypervisor ballooning and swap interact on some VPS platforms — read provider doc before tuning swappiness to zero aggressively.
Operational follow-up
Document swap baseline post-incident — future comparison. Alert swapin correlated with latency. OOM killer log review after swap spike — which process victim. Document gaps between host marketing and field measurement in the quarterly review.
Quarterly follow-up
Document swap baseline post-incident — future comparison. Alert swapin correlated with latency. OOM killer log review after swap spike — which process victim. Document gaps between host marketing and field measurement in the quarterly review.
Keep a dated runbook, before/after metrics, post-incident review — cumulative discipline beats Friday night panic.
Keep a dated runbook, before/after metrics, post-incident review — cumulative discipline beats Friday night panic.
Keep a dated runbook, before/after metrics, post-incident review — cumulative discipline beats Friday night panic.
Keep a dated runbook, before/after metrics, post-incident review — cumulative discipline beats Friday night panic.
Keep a dated runbook, before/after metrics, post-incident review — cumulative discipline beats Friday night panic.
Keep a dated runbook, before/after metrics, post-incident review — cumulative discipline beats Friday night panic.
Swap matrix
| Signal | Action |
|---|---|
| swap used, swapin ~0 | monitor |
| swapin + latency | RAM upgrade |
| Redis swap | fix now |
Java and batch
Xmx near container limit = pain. OK nightly batch swap if documented.
Decide and move forward without blind spots
- Correlate swapin/out and app latency — used swap without activity = monitor; sustained swapin = RAM ticket.
- Three-panel dashboard — RAM available, swap I/O, p95 latency overlay.
- Never Redis or DB in swap — immediate fix if detected.
- Document acceptable nightly batch — predictable swap vs memory leak.
- Review after cloud instance change — RAM/swap ratio shifts with type.
RAM upgrade: numbers in hand via our comparison tool and directory sheets.
Frequently asked questions
100% swap = emergency?
Emergency if latency spikes and active RAM mostly swapped (low available). Can be benign if cold inactive pages.
swappiness 60 or 10?
10–20 on prod DB/cache servers. 60 is desktop-default.
Disable swap?
Rarely on small VPS — some swap avoids brutal OOM. Critical DB: more RAM beats zero swap.
zram useful?
On tight small VPS, zram compresses in RAM — better than slow disk swap, not real RAM for large working sets.
Check vmstat before buying cloud swap — sometimes you need 4 GB RAM, not 4 GB swap.