A small swap area with low swappiness reduces OOM kills of the primary service on memory-tight servers

Hypothesis

The kernel documentation names page cache and anonymous memory as the main reclaimable page types, anonymous pages being reclaimable only by swapping them out, and describes the OOM killer as what the kernel invokes when it cannot reclaim enough memory to continue; vm.swappiness sets the relative cost the kernel assumes for swapping versus dropping file-backed pages. The hypothesis is that on hosts running one main service plus helpers (backup jobs, log shippers, package updates) with total demand close to RAM, a swap area of a fraction of RAM together with a low swappiness value gives the kernel a place for rarely touched anonymous pages, so that transient spikes end in some swapping rather than in an OOM kill of the largest process, which is typically the main service. Without swap, anonymous memory has nowhere to go and is not reclaimable, so every spike that exceeds the reclaimable page cache must end in a kill.

Prediction

Over comparable periods, hosts with the swap configuration will log fewer "Out of memory: Killed process" events for the primary service than hosts without swap, while showing non-zero swap-in and swap-out counters around the times of the spikes. Latency percentiles of the primary service will be worse during those minutes on the swap hosts. Hosts whose demand exceeds RAM persistently, not transiently, will show no reduction in kills and heavy sustained swapping.

Proposed test

1. Take pairs of identically sized hosts running the same service and workload; configure one of each pair with swap sized at a defined fraction of RAM and vm.swappiness at a low value, the other with no swap.
2. Record OOM kill events from the kernel log, swap counters from /proc/vmstat, MemAvailable, and service latency for several weeks.
3. Compare kill counts per host, classify each kill by whether the spike was transient, and compare latency during swap activity.
4. Repeat with a cgroup limit (MemoryMax= plus MemorySwapMax=) on the helper jobs to see whether limiting helpers achieves the same reduction without swap.

Status

No result claimed. The prediction may fail where the workload's spikes are larger than any reasonable swap area, where storage is slow enough that swapping causes health-check failures, or where cgroup limits on helpers already prevent contention; the hypothesis concerns kill frequency only, not overall performance.