Linux Swap: Read the Metrics and Understand Swappiness, zram and zswap

Used swap does not prove that a Linux machine is short of RAM right now. Separate the amount already stored in swap from ongoing page movement. This article explains how to observe both, interpret swappiness and distinguish disk-backed swap from zram and zswap before considering configuration changes.

The commands below are read-only Linux observations: they do not create or disable swap or change kernel settings. This is documentation-based guidance, not a benchmark or measurements from the reader's machine. Package names and tool availability vary by distribution.

1. Read available before reacting to swap used

In free(1), available estimates memory usable by new applications without swapping, accounting for reclaimable memory. Low free memory alone therefore does not establish an imminent shortage.

As an illustration, a machine may still show 1 GiB of used swap after a load spike while available memory remains stable and applications respond normally. That number alone is insufficient evidence of an active incident. Observe trends and application behavior rather than treating zero used swap as a universal goal.

2. Collect a read-only baseline

uname -r
free -h
swapon --show
vmstat 1 10
cat /proc/pressure/memory
sysctl vm.swappiness

swapon --show lists active swap areas with information such as type, size, usage and priority, as documented in swapon(8). An empty data listing normally means no active swap in the observed system context; distinguish that from a missing command or execution error.

If /proc/pressure/memory is absent, check kernel support and the environment rather than interpreting absence as zero pressure. Containers or restricted environments may expose information that does not fully describe workload limits; compare it with their resource-management configuration.

3. Separate capacity from paging rate

vmstat(8) defines swpd as swap used and si/so as swap-in/swap-out rates. The first report includes rates averaged since boot; subsequent reports cover the sampling interval. Memory and process fields remain instantaneous.

With vmstat 1 10, do not treat the first line as the previous second's rate. Examine later samples during the slowdown. When compressed RAM swap is involved, do not equate every swap operation with physical SSD traffic.

This is a reasoning framework, not a definitive diagnostic rule. Short samples can miss an earlier burst.

4. Add PSI as another signal

Pressure Stall Information describes resource-related stalls. For memory, some measures time with at least one stalled task, while full concerns all non-idle tasks stalled together. avg10, avg60 and avg300 describe time-window averages, not percentages of RAM occupied.

Compare pressure with response times, work volume and worker counts. A recent concurrency increase followed by rising pressure is a hypothesis worth testing. No single PSI threshold fits every machine or latency requirement.

5. Swappiness is not a RAM percentage trigger

The kernel documentation describes swappiness on a 0–200 scale expressing relative swap versus filesystem paging costs. It does not mean “wait until RAM is X percent full.” Zero does not disable swap.

Do not copy a supposedly universal server setting. Record the original value, swap backend, workload and measurable objective. Change one factor at a time under controlled conditions, compare equivalent workloads and prepare rollback. This article does not ask readers to change production swappiness.

6. Disk swap, zram and zswap

zram creates compressed RAM-backed block devices that can serve as swap. It still consumes physical memory and compression resources; configured logical capacity is not newly added physical RAM.

zswap is a compressed cache for pages being swapped out and can evict pages to backing swap. It is not the same arrangement as using a zram device as swap. Disk-backed swap files and partitions have different storage characteristics.

Do not stack mechanisms simply because their names sound related. Identify what the distribution already configures and which component manages it. Evaluate RAM, CPU, storage and workload together instead of comparing displayed swap capacity alone.

7. Avoid reflexively “clearing swap”

Disabling swap changes system state; it is not harmless cleanup. The swapoff documentation includes failure due to insufficient memory to stop swapping. On a pressured machine, forcing the used-swap counter toward zero can make operations harder to control.

Do not run swapoff -a, recreate swap or edit boot configuration because of a single graph. Planned changes need a maintenance window, capacity review and recovery plan. If an application retains ever more memory or runs too many workers, changing swap does not address that cause.

8. Before intervening

• Distinguish used swap from swap-in/out rates over time.
• Correlate available memory, PSI where supported and application latency.
• Identify disk-backed versus compressed-memory mechanisms.
• Review workload and configuration changes near the onset.
• Record a baseline, success criteria and rollback plan before tuning.
• Do not define system health solely as zero used swap.

Swap is part of memory management, not an error by itself. Safer operation comes from interpreting measurements correctly, testing hypotheses across several signals and changing configuration only for a measurable objective.