Linux Swap and OOM Killer Behavior on Memory Constrained Servers

On a memory constrained Linux server, swap gives the kernel breathing room by moving rarely used pages to disk, while the OOM killer is the last resort that terminates a process when memory runs out. A small amount of swap usually makes a server more stable, but heavy swapping makes it slow. The goal is to leave headroom, set limits per service, and alert before the OOM killer has to act.

What Does Swap Actually Do?

Swap is disk space the kernel can use as an extension of memory. It does not make the machine faster. Its main value is that the kernel can move anonymous memory that has not been touched recently, such as idle parts of a process, out of RAM, freeing physical memory for active data and the page cache.

That is why having some swap is often beneficial even when memory is not full. Moving cold pages out leaves more room for file caching, which speeds up disk reads. Problems start when the working set itself does not fit in RAM. The system then constantly moves pages in and out, a state called thrashing, and latency rises sharply.

Swap on slow disks makes thrashing worse, and on some cloud instances, disk throughput is limited, so the effects can be dramatic. Check how your provider treats swap and disk performance before depending on it.

What Does swappiness Control?

The vm.swappiness setting influences how aggressively the kernel prefers swapping anonymous memory versus reclaiming file cache. Lower values make the kernel favor dropping cache, while higher values make it swap more readily. The exact semantics and defaults have changed across kernel versions, so read the kernel documentation for the version you run.

cat /proc/sys/vm/swappiness
sudo sysctl vm.swappiness=10
free -h
vmstat 1 5

Treat swappiness as a tuning knob, not a fix. If a server is swapping heavily during normal operation, it needs more memory, lower memory use, or fewer co-located workloads, and no setting will remove that need.

How Does the OOM Killer Decide What to Kill?

When the kernel cannot reclaim enough memory, the OOM killer selects a process to terminate. It scores processes based mainly on memory usage, adjusted by oom_score_adj, which you can set per process to make it more or less likely to be chosen. The decision is made in kernel context and may not match the process you consider least important.

• Check kernel logs with dmesg or journalctl -k for messages about killed processes.
• Use oom_score_adj to protect critical services, or to sacrifice batch jobs first.
• Remember that containers have their own memory limits, and an OOM kill inside a cgroup is a separate event from a host-wide one.
• Do not disable the OOM killer globally, because the system may then hang instead of recovering.

Overcommit settings also play a role. Linux allows processes to allocate more virtual memory than physically exists, and the consequences appear only when the memory is actually used. Review vm.overcommit_memory in the documentation before changing it.

How Should You Prepare a Small Server?

Prevention beats recovery. Define memory limits for each service, whether through systemd, containers, or runtime settings such as a heap size, so one process cannot take everything. Leave a margin for the kernel, the page cache, and spikes.

• Monitor available memory, swap usage, and swap in and out rates, and alert on sustained swapping.
• Add a modest swap file or partition as a safety buffer, rather than relying on it for normal operation.
• Size application pools, caches, and worker counts to fit within available memory.
• Consider an early OOM daemon or memory pressure information, where your distribution supports it, to act before the kernel killer does.

Frequently Asked Questions

Should I disable swap on a server?

Not automatically. Some workloads, such as certain databases and orchestrators, recommend specific swap settings, so follow their documentation. For general servers, a small swap often improves stability.

How much swap do I need?

There is no universal ratio. A modest amount as a safety buffer works for many servers. Base the decision on workload and monitoring.

Why was my process killed even though swap was free?

It may have hit a cgroup memory limit, or the kernel could not reclaim memory fast enough. Check the kernel log for details.

How do I find out what the OOM killer terminated?

Search the kernel log for out of memory messages, which list the victim process and memory statistics at the time.

Summary

Use a small swap as a buffer, set per-service memory limits, monitor swapping, and protect critical processes with oom_score_adj. Check kernel documentation for the exact behavior of swappiness and overcommit on your version.