Configuring Swap and OOM Killer for Memory Management

Configuring Linux swap: why a service crashes during a memory spike

An emergency service restart happens at the height of peak server load, even though monitoring at the same moment shows free memory.

This is not a charting error: a lack of RAM manifests not in the total volume but in the availability of pages in the required zone and in the kernel's ability to allocate a contiguous region.

In Linux logs, it looks like this: the oom killer terminated the process, and the supervisor brought it back up.

The kernel selects the victim based on oom_score adjusted by oom_score_adj, and most often it is the main worker process rather than the one that accumulated the leak: a long-lived service has higher consumption — and therefore a higher chance of being terminated.

The restart restores connections but loses unwritten transactions, and after a few minutes the picture repeats if the cause has not been eliminated.

Configuring Linux swap in this scheme is not "adding slow memory" but giving the kernel a time buffer: offload cold pages instead of immediately terminating a process on the very first spike.

vm.swappiness determines how readily anonymous pages are evicted, while cgroup limits and vm.overcommit_memory mode determine who is allowed to occupy how much in the first place.

We explain how this is addressed: by which metrics the approach to failure is visible before the OOM itself, how limits are calculated by process groups, and what to do if the service's working set no longer fits in memory.

The effect of managed swapping: response and stability

The effect of managed swapping is visible not from the free memory graph but from the number of incidents.

After swap and the policy for responding to memory shortage are tuned to the load profile, the service during peaks enters predictable degradation: some operations slow down, but processes do not die and do not drag their neighbors down with them. Below are the checks by which we accept the work.

• Emergency restarts. The number of process crashes due to memory shortage drops by an order of magnitude: instead of dozens of events, only isolated ones remain, and each is investigated as an anomaly rather than as background noise.
• Predictable degradation. Under peak load, response time grows, but queues do not break: cold pages go to swap, the hot working set remains in memory, and service failure does not occur.
• Even response to bursts. The free-page threshold and eviction aggressiveness are set for the load, so short bursts pass without outages — the service slows down smoothly rather than being cut off.
• Isolation of consequences. Memory limits for process groups and the early killer based on memory pressure deal only with the problematic service; neighbors on the same machine do not lose availability.
• Eliminated incident class. Night-time escalations and on-call pages due to memory crashes leave the flow — what remains are tasks for planned expansion, not firefighting.
• Fast recovery. After the peak, the service returns to operating mode within tens of seconds, without re-warming the cache or manual intervention.

Each item is verified on a test bench with a reproducible load profile: we capture metrics before and after, compare restart frequency and behavior at the limit. This is how the swapping effect becomes measurable rather than declarative.

Ways to organize swapping: comparison and limitations

The choice of swap medium determines not only the available volume but also response time at the moment memory is exhausted.

The kernel polls active swap areas in descending order of priority, so a swap file on a fast local drive and a capacious partition on a slow array can coexist peacefully: hot pages go to the fast one, cold pages to the large one. The mistake begins where a medium not designed for constant writes is allocated for swap.

The priority of swap areas is set explicitly — in the filesystem entry or with a mount option — otherwise the fill order will be random.

swappiness is selected according to the load profile: for services with a large file cache, the value is lowered; for virtual machines and thin clients, it is raised.

The decision is made not by taste but by page-fault miss counters and memory pressure data — then swapping absorbs peaks rather than masking a memory shortage.

Workflow: from memory audit to handover of procedures

We start not with editing configuration but with facts: without a consumption profile, any memory parameter tuning turns into guesswork.

This order eliminates the typical scenario where swap is enabled "just in case" and results in a response drop or a sudden service restart during peak hours.

1. Memory consumption audit. We capture metrics by processes and groups: peak and average consumption, share of anonymous pages, behavior during load hours. Separately, we look at who holds memory after a spike.
2. Swap placement scheme. We determine whether a swap file or a separate partition is needed, on which medium, and of what size. We record which data may be evicted and which must remain in RAM.
3. Setting thresholds and emergency termination. We set eviction intensity, limits for process groups, and the priorities by which the kernel selects a victim during memory shortage. Explicit priorities are more reliable than automatic selection.
4. Load testing. We run scenarios with artificial memory shortage and observe the result: whether response latency grows, whether emergency termination triggers, and which processes die first.
5. Observability. We set alerts for approaching limits, growing eviction, and the fact of emergency termination — the incident becomes visible before the service goes down.
6. Handover of procedures. We provide the swap placement scheme, parameter values with rationale, the rollback procedure, and a checklist of actions for a sharp increase in consumption.

Set of documents and configurations after implementation

After implementation, the team retains not only working settings but also documents by which they can be changed and handed over without us. Below is a list of artifacts the customer receives along with the result.

Each is designed for the on-call engineer, who will open it at the moment of an incident, rather than "someday we'll read it."

• Swap configuration — file or partition with an fstab entry, values for vm.swappiness, overcommit, and cache_pressure, with a comment nearby: why this behavior was chosen and what will change if default values are restored.
• Per-service policies — memory limits in cgroup and oom_score_adj priorities: who gets a chance to survive under pressure, and whom the kernel frees first.
• Placement scheme — on which node and medium the swap area resides, how it relates to data volumes, and where the disk I/O bottlenecks are.
• On-call shift procedure — step-by-step actions for growing memory consumption and OOM Killer triggers: what to check, what to restart, when to call the senior engineer.
• Memory documentation — consumption profile by service, normal thresholds, typical causes of growth, and a change log of settings.
• Checks and rollback plan — metrics, alerts, and diagnostic commands in ready-to-use form, plus the procedure for reverting to the previous profile if changes worsened service behavior.

Separately, we record owners: who on your team reviews limits as load grows, and by which signs a review is triggered.

Case: eliminating emergency restarts during peaks

Under load, the service behaved steadily, but during peak hours it hit the memory ceiling. Unable to find free pages, the kernel forcibly terminated the heaviest processes — and the entire node went down with them.

The result: seven incidents per month, each with manual investigation; recovery took up to 45 minutes, and some requests were lost during that window.

What was changed

We separated two different scenarios — a short burst and sustained memory shortage. For bursts, we allocated a swap area on a separate volume: it gives the kernel a buffer to wait for memory to be freed rather than terminating processes.

For containers, we set hard limits and a termination order — the background worker goes first, while the frontend service stays in service.

Consumption was monitored via Prometheus: the alert for sustained growth was configured to trigger before the emergency mechanism. This enabled root-cause analysis before the failure, not after.

The changes were validated over three months of observation. Summary before and after:

At the same time, swapping does not mask a leak: if consumption grows linearly, an alert arrives, and the cause is investigated before the reserve runs out.

How does a swap file differ from a separate partition?

From the kernel's point of view, there is almost no difference: both a file and a partition become a block device after initialization, which is mounted with a single command. The difference appears in how this volume is created, changed, and survives disk reassembly.

A dedicated partition is a pre-cut piece of the partition table. The kernel accesses it directly, without a filesystem layer, so I/O overhead is lower and behavior under load is more predictable.

The price is rigidity: the size is fixed at partitioning time, and changing it requires modifying the partition table and often rebooting. This option is chosen where swap is tied to hibernation: the kernel needs a contiguous disk region described in boot parameters.

A swap file lives in an existing filesystem. It can be created and attached on the fly, its size can be changed without stopping services, and multiple files with different priorities allow spreading the load across different disks.

Limitations are inherited from the filesystem: on some network and copy-on-write storage such a file does not work, and for hibernation it requires manual calculation of the offset.

This directly affects partitioning: a partition consumes space in advance and forces planning the scheme at installation, while a file keeps the layout flat and lets you tune swap size to the actual load.

Hence the choice: physical servers with hibernation — a partition; virtual machines, container hosts, and cloud — a file, because changing the partition layout there is more expensive than removing or adding a file.

Frequently asked questions about system behavior during memory shortage

Before work begins, the same doubts come up: will the service start crashing more often, will response drop, what will change in containers, and can we avoid rebooting the node.

Some questions are resolved during diagnostics — process kill counters, vmstat statistics, and cgroup limits show what is happening now and what it threatens under load.

Is swapping needed if there is enough RAM?

Swapping does not speed things up, but it holds a reserve for peaks: rarely used pages go to disk instead of triggering a process kill. It should be disabled only where predictable latency matters — and then limits are set more strictly, with an explicit reserve for peak load.

Will the service become slower?

As long as active pages remain in memory, response does not change. Degradation begins during active eviction: it is visible in the I/O fields in vmstat and in growing response time. That is why swappiness is selected for the load profile rather than left inherited.

How does this work in containers, and can it be applied without a reboot?

Inside a container, group limits apply rather than node memory: the host kernel selects the victim, but according to priorities within the group, so parameters are coordinated at two levels.

Most values can be changed on the fly; the rest are fixed in configuration — there is no need to reboot the node, just restart the container.

Let's discuss the task and come back with an implementation plan

The start is always the same: first an analysis of the situation, then an estimate and implementation plan, and only then changes on live servers.

We do not touch memory parameters "by feel" — first we need to see how swap and the emergency process termination mechanism behave under your real load.

For this, a description of the task and access to system monitoring are enough, rather than full production access at the first step.

• Situation analysis. We record which services run on the host, what their memory consumption peaks are, and what has already happened: whether there were restarts, "freezes" under load, or sudden process crashes.
• Initial data collection. We review current swap parameters, memory limits for containers and services, and the history of emergency process termination triggers. This answers the question of where exactly memory is being lost.
• Work estimate. We determine the scope of changes, the order of steps, maintenance windows for edits, and rollback points. You receive an estimate and plan before anything changes on the servers.
• Implementation plan. We agree on which thresholds and priorities to set, which processes to protect from termination, and how to configure emergency memory release so that it hits the right target.
• Implementation and verification. We change the configuration, run the load profile, and make sure that under peak load the system does not go into restart. The result is predictable behavior instead of sudden crashes.
• Handover. We provide configurations, the scheme of decisions made, and the metrics by which the changes are visible on graphs.

To get started, describe the task: which services are involved, which symptoms are concerning you, and what you have already tried. We will come back with an estimate and implementation plan — with no obligation to start work immediately.