Q: A database server has 64GB of RAM and Swap enabled. Swappiness is set to the default of 60. You notice the database occasionally acts sluggish because Linux is using 5GB of Swap, even though 10GB of RAM is perfectly free. You disable Swap entirely via `swapoff -a` to force it entirely into RAM, and sudden OOM Outages begin. Explain this behavior.
Linux actively manages memory between Application Memory (Anonymous) and File Caching (Page Cache).
🛠️ Production Runbook & Step-by-Step Resolution
Production Solution & Architecture
Linux actively manages memory between Application Memory (Anonymous) and File Caching (Page Cache). A swappiness of 60 aggressively pages out idle, rarely used application memory to the relatively slow Swap partition to free up RAM so Linux can cache heavily requested disk files, speeding up overall I/O. When you ran swapoff, you ripped away the safety net. Now, when the database makes a sudden, massive memory allocation request, Linux has no Swap to move the idle pages to. It must furiously drop disk caches to find space. If the cache dropping isn't fast enough to satisfy the allocation speed, the kernel enters an Out Of Memory condition and the OOM Killer aggressively terminates the database to save the OS. *Fix:* Turn Swap back on, but drastically tune sysctl vm.swappiness=1 (or 10) to instruct the kernel to only swap out memory absolutely as a last resort before an OOM.
- Immediate Triage: Linux actively manages memory between Application Memory (Anonymous) and File Caching (Page Cac
- Run targeted verification commands before modifying configuration.
- Automate permanent guardrails (CI check, alerts, IaC policy) to prevent recurrence.