Mental model
When physical RAM runs low, the kernel reclaims memory by dropping anonymous pages to Swap space or evicting page cache. If physical memory and swap are completely exhausted, the Linux OOM (Out-Of-Memory) Killer selects and terminates the process with the highest oom_score.
Theory
vm.swappiness(0-200): Controls the kernel's aggressiveness in swapping out anonymous memory relative to page cache eviction. Default60. Setting10preserves RAM for database application memory pages.- OOM Killer Scoring (
oom_score): Calculated based on percentage of RAM consumed by the process tree. - Adjusting Priority (
oom_score_adj): Value ranging from-1000(never terminate) to+1000(first candidate for termination).
Alternatives and trade-offs
- Aggressive Swappiness (
vm.swappiness = 60): Prevents OOM crashes by spilling to disk; degrades system responsiveness due to swap disk thrashing. - Low Swappiness (
vm.swappiness = 10): Keeps application memory in fast physical RAM; requires strict memory monitoring to avoid sudden OOM killer invocations.
Failure modes and misconceptions
- Silent Production Daemon Termination: Failing to protect critical backend services (PostgreSQL / Redis) with
oom_score_adjcauses the OOM killer to terminate database master processes during memory spikes. - Swap Thrashing Latency Spikes: Allowing high-throughput databases to use swap disk leads to major page fault thrashing, causing latency spikes exceeding 10 seconds per query.
Decision scenario
Set vm.swappiness = 10 and adjust oom_score_adj = -1000 on critical database master processes to prevent latency thrashing and OOM killer termination.
Learning outcomes
- Tune
vm.swappinessparameters for low-latency server workloads. - Calculate kernel
oom_scoreheuristics during memory pressure events. - Protect critical production daemons using
oom_score_adjoverrides.
Trade-offs
The OOM killer prevents total host kernel lockups during memory exhaustion, but unconfigured deployments risk losing critical database daemon processes.