Linux Swap Subsystem & OOM Killer

Learning outcomes

• Configure swappiness and memory pressure thresholds
• Protect critical daemon processes from OOM killer termination

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. Default 60. Setting 10 preserves 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).

# Check current system swappiness
cat /proc/sys/vm/swappiness

# Protect critical daemon process (e.g. PostgreSQL master) from OOM Killer
# Set oom_score_adj to -1000
echo -1000 > /proc/sys/fs/cgroup/system.slice/postgresql.service/memory.oom.group
# Or via procfs for PID 1234
echo -1000 > /proc/1234/oom_score_adj

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

1. Silent Production Daemon Termination: Failing to protect critical backend services (PostgreSQL / Redis) with oom_score_adj causes the OOM killer to terminate database master processes during memory spikes.
2. 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.swappiness parameters for low-latency server workloads.
• Calculate kernel oom_score heuristics during memory pressure events.
• Protect critical production daemons using oom_score_adj overrides.

Trade-offs

The OOM killer prevents total host kernel lockups during memory exhaustion, but unconfigured deployments risk losing critical database daemon processes.

Primary sources

• Linux Kernel Kernel.org Official Architecture & Systems Documentation — Linux Kernel Organization, verified 2026-07-23