Context
A dashboard shows used swap and an administrator proposes disabling it. Occupied swap is not the same as active swapping, and neither alone proves that users are waiting. Linux may retain cold pages in swap after an earlier pressure period while useful work proceeds normally. The investigation should connect current reclaim activity with application behavior.
Prepare the host's memory design, swap implementation, workload history and latency timeline. Identify whether swap is backed by a disk, compressed memory or another supported mechanism. Do not run swapoff merely to clean a graph: it forces pages back toward memory and can create pressure while the server is already busy.
Measure activity over an interval
- Read
free -handswapon --showto understand available memory and configured swap devices. Compare memory availability with the workload rather than focusing only on the free column. File cache and anonymous application memory have different reclaim behavior. Record total swap, current usage and the actual backing type before discussing a tuning change. - Use
vmstat 1 10or an existing monitoring collector to inspect swap-in and swap-out activity across several samples. Interpret the initial line according to the tool's documentation; it can summarize a longer period than subsequent lines. Correlate sustained activity with the exact application slowdown, not with a historical maximum from another time. - Review memory pressure and reclaim evidence through
/proc/pressure/memorywhere available and the host's established memory metrics. A process can encounter reclaim delays before a dramatic swap-usage increase. Conversely, high occupancy with little current movement may reflect an old, cold working set. Check recent deployment or batch activity to explain changed demand. - Read
sysctl vm.swappinesswithout altering it. The kernel documents a relative cost preference between swapping and filesystem paging. The appropriate setting depends on workload and backing storage; it is not the fraction of RAM that may be used, and a value copied from another server does not establish a suitable policy here.
An illustrative stale occupancy graph
In an illustrative reporting host, a weekend import pushes cold administration pages into swap. On Monday, swap usage remains visible, but normal reports have no swap-in bursts or added latency. Clearing swap would change occupancy while providing no demonstrated user benefit. The team keeps the signal as context and investigates only if current pressure or service behavior changes.
| Observation | Supporting check | Interpretation |
|---|---|---|
| Swap used, little movement | Interval activity and latency | Historical occupancy may be harmless |
| Sustained swap-in with slow requests | Memory pressure and working set | Active contention needs attribution |
| Swap-out during a batch | Competing demand and cache behavior | Evaluate workload scheduling |
| Compressed swap configured | Backing type and CPU cost | Storage assumptions differ |
Correct the demonstrated demand problem
Possible responses include fixing an application memory leak, reducing unnecessary concurrency, moving a competing job or adding measured capacity. A swappiness experiment should have a hypothesis, representative workload and rollback setting. Changing the preference cannot create physical memory or repair an unbounded working set.
Verify service completion times, reclaim and swap activity after the correction under comparable demand. Check that filesystem performance did not worsen while swap movement fell. A lower swap number is not acceptance if user work became slower or was rejected.
Document a memory SOP
Monitor current pressure and application success alongside occupancy. Record swap backing, tuning ownership and the evidence needed before disruptive changes. Escalate with interval samples and workload context. Clouvenix server performance can help separate capacity planning from cosmetic metric changes.