RAM, paging and swap pressure

What it means

A page is a unit of memory managed by the operating system. Resident means currently held in physical RAM. Here, the active working set is the set of pages the workload needs to access during the selected scenario—not simply everything it has allocated.

The exercise compares that active demand with a declared resident-capacity budget. Available resident capacity is an input you supply, not automatically the server’s installed RAM or a reading from a monitoring tool. The difference shows a mismatch under the stated assumptions; it does not predict the kernel’s next action.

Try it

Simulation: inspect the baseline, then change Available resident capacity (GiB) from 4 to 8. Leave the other two inputs unchanged. Select Compare with baseline to see the two outcomes together and read why they differ. Editing an input clears the comparison; Reset restores the baseline.

The baseline result is “2 GiB illustrative pressure beyond RAM.” Swap may allow backing some pages but can incur substantial I/O and does not guarantee responsiveness. This is a local budget calculation, not a measurement of swap activity or an OOM forecast.

Keep Active working set (GiB) at 6 and Swap available? at yes. Only the declared resident-capacity budget changes.

Reset restores Available resident capacity (GiB) to 4, Active working set (GiB) to 6 and Swap available? to yes. It removes input errors and clears the baseline comparison. There is no running clock or stored event history. Your independently opened or closed FAQ answers and About this model panel stay as you left them.

How it works

RAM keeps resident pages directly accessible without first retrieving them from backing storage. When the pages a workload actively needs cannot all remain resident, the operating system’s choices depend on what can be reclaimed and how those pages are backed. For example, a clean file-backed cache page can be discarded and read again from its file when needed. A modified file-backed page generally needs writeback before its memory can be reclaimed. Anonymous application data has no file copy to reread; eligible anonymous pages can instead use swap backing. Not every page is reclaimable, and not every reclaimed page goes through swap.

The performance consequence depends on what happens next. If a needed page is no longer resident and must be retrieved through storage I/O, accessing it involves more than a RAM access. Repeatedly needing such pages can create substantial I/O and poor responsiveness even when backing is available. Swap availability therefore answers a different question from whether the active workload can remain resident.

The lab deliberately reduces that mechanism to a capacity comparison. It first calculates the excess of active demand over the declared resident budget, then uses the swap flag to qualify the explanation. It never calculates which pages would move, how much I/O would occur or whether an allocation would succeed.

Worked example

This is a synthetic baseline, not a captured production observation.

The calculation is max(0, 6 − 4) = 2 GiB. Under these assumptions, 2 GiB of active demand lies beyond the resident budget. Because swap is marked available, the explanation allows for backing some pages while warning about I/O and responsiveness.

The intermediate quantity matters: it is a budget excess, not 2 GiB that the model has observed being written to swap. The same subtraction cannot tell you which pages are reclaimable or how soon the workload will need them again.

What changes when the condition changes

Change Available resident capacity (GiB) from 4 to 8, keeping Active working set (GiB) at 6 and Swap available? at yes. The result becomes “Fits in modeled RAM.” The explanation is: “The workload fits this simplified resident budget.”

The active demand has not fallen; the declared budget has increased enough to contain it. The modeled excess therefore falls from 2 GiB to 0 GiB. This overturns the idea that the working-set size alone determines pressure: the same 6-GiB workload produces a different result under a different capacity budget. It does not establish that a real server would stop swapping or meet a response-time target.

In practice

On a Linux server you administer or have permission to inspect, start with read-only observations for the affected workload and its containing cgroup, if one is used. Compare resident use, available capacity, cache, swap activity and application response times over the same period. For cgroup v2, include the affected cgroup’s memory.max and memory.events rather than relying only on host totals.

Look for evidence that distinguishes the possibilities: reclaimable cache is not the same observation as an active working set that cannot remain resident, and a workload-specific limit is not the same as exhausted host RAM. Reclaim or swap activity alongside slower responses can support further investigation, but that overlap alone does not prove the cause of the slowdown.

Do not disable swap, clear caches or change limits simply to make a free-memory number look larger. STOP before any configuration change if the affected workload, effective limit or working-set estimate is unknown, or if you lack authorization. This page recommends observation, not a production mutation; the simulation supplies neither a change plan nor a rollback procedure.

Limits and unknowns

The scene does not observe your server or estimate a working set from it. It has no OS allocator, reclaim heuristics, swap-in/out latency or true OOM prediction. It also does not model reclaimable cache, page types, swap capacity or cgroup policy. Its numeric excess is therefore neither a measured amount of swapped data nor a diagnosis of memory-related slowness.

To examine the no-swap branch separately, return to the baseline capacity of 4 GiB and working set of 6 GiB, then select no for Swap available?. The result is “Working set exceeds modeled RAM without swap.” That identifies the declared budget mismatch; it does not prove that the real kernel would immediately kill a process. Reclaim and allocation policy remain outside the model.

Use capacity values from 1–128 GiB and working-set values from 0–256 GiB, in 0.1-GiB increments. Empty or invalid input removes the calculated outcome until you correct it or use Reset; an earlier valid result must not be treated as applying to the current input. If the real capacity or working set is unknown, the simulation cannot fill in that missing evidence.

Without JavaScript, the initial example and explanations remain readable, but the controls are unavailable. No external check or server change is performed.

What to carry forward

Treat memory shortage as a relationship between the workload’s active needs, the capacity available to it and the ways pages can be reclaimed or backed. Swap availability alone cannot establish acceptable performance. Before choosing a remedy, identify the affected workload’s effective limit and compare memory activity with its response times.