Linux swap management: choose a supported device and measure memory pressure
Swap gives the kernel somewhere to place eligible memory pages outside RAM. It can improve resilience under some workloads, but it does not make storage equivalent to memory and it does not guarantee that an out-of-memory event cannot happen. Begin with the existing configuration and measured pressure before adding capacity or changing reclaim policy.
In this guide
- Linux swap management: choose a supported device and measure memory pressure
- Inspect before making changes
- Size swap for the workload, not a universal RAM ratio
- Create a new swap file without overwriting an existing one
- Persist only the intended entry
- Why ZFS zvol swap is not a guaranteed fix
- Swappiness is a reclaim preference, not a RAM-full trigger
- Remove or resize swap with a capacity check
- A useful verification record
- Questions readers often ask
For a supported ordinary filesystem such as ext4, a correctly allocated swap file is a common option. For a ZFS host, do not assume that putting swap on a zvol eliminates memory-pressure deadlock. OpenZFS explicitly documents that risk. A dedicated supported non-ZFS swap device avoids relying on the ZFS allocation path for that swap, subject to the host’s storage and security requirements.
Inspect before making changes
swapon --show
free -h
findmnt -no FSTYPE -T /
df -h /
cat /proc/sys/vm/swappiness
Read available memory alongside total and used values. Cache is not automatically wasted memory, and allocated swap is not the same as active paging. Existing swap may already come from a partition, a file, or compressed RAM. Do not add a second configuration by blindly assuming the installation has none.
To observe activity, use:
vmstat 2
The first report has different averaging context from the following interval reports. Read subsequent si and so activity, process behaviour, and latency together. Some pages sitting in swap with little current traffic do not prove a memory leak. Sustained paging and slow response deserve investigation, but the diagnosis is not established by one arbitrary swap-used threshold.
Size swap for the workload, not a universal RAM ratio
A workload with short peaks, a latency-sensitive service, a desktop using hibernation, and a container host can have different requirements. Measure peak demand and decide what failure behaviour is acceptable. More swap can postpone an OOM event while making a badly oversized workload slow for longer.
Hibernation has additional image-size, resume, encryption, and platform constraints. “Swap must always equal all installed RAM” is not a complete rule, and a small server-style swap recommendation should not be presented as a hibernation guarantee. Use the operating system’s actual hibernation requirements for that use case.
Create a new swap file without overwriting an existing one
The following example allocates 8 GiB on an ordinary filesystem that supports swap files. It is an example size, not a recommendation for every machine. Check the target filesystem, capacity, active swap, and path first. Do not use this as a recipe for a ZFS dataset, a filesystem with unsupported copy-on-write behaviour, or an existing active swap file.
# Choose a new path; stop if it already exists, including a symlink.
# The subshell stops on failure without exiting your interactive shell.
(
set -eu
swap_path=/swapfile-extra
if sudo test -e "$swap_path" || sudo test -L "$swap_path"; then
printf '%s\n' 'The chosen swap path already exists.' >&2
exit 1
fi
# Run on a verified supported filesystem with sufficient free space.
sudo install -m 600 /dev/null "$swap_path"
sudo dd if=/dev/zero of="$swap_path" bs=1M count=8192 status=progress conv=fsync
sudo chmod 600 "$swap_path"
sudo mkswap "$swap_path"
sudo swapon "$swap_path"
swapon --show
)
Stop on a failed command and investigate it before continuing. In a script, use explicit error handling or a suitable fail-on-error policy. dd‘s example size is 8 GiB because its 1M block size is binary here; it is not a measured completion time. Actual output depends on the filesystem, page size, and machine.
The pathname check is a practical guard for a single-administrator procedure, not a locking protocol for concurrent privileged automation. Production configuration tooling should manage the resource declaratively and reject concurrent changes.
mkswap formats the chosen target. It must never be aimed at a data partition or volume you intend to preserve. Keep the file permissions restrictive because swap can contain sensitive process memory. Verify activation rather than assuming that formatting also enabled the device.
Persist only the intended entry
Back up and inspect /etc/fstab before editing it. Add the following entry once for the specific file created above:
/swapfile-extra none swap sw 0 0
Use an editor or configuration manager that preserves existing mounts and avoids duplicate entries. Do not replace the whole file with a redirection, and do not keep appending the line each time you rerun the guide. Inspect it after editing and validate the configuration with the tools available on the distribution.
Activation with swapon tests the current setup. Persistence still needs verification after a planned restart under controlled conditions. Record the expected path and compare it with swapon --show afterwards; a successful current activation is not proof of boot ordering.
Why ZFS zvol swap is not a guaranteed fix
A zvol presents a block device, but its I/O still depends on ZFS. Settings such as primarycache=metadata can change caching behaviour; they do not turn it into an independent non-ZFS device. OpenZFS documents possible deadlock under memory pressure for swap on zvols.
The earlier idea that a specific zvol parameter list removes the risk is therefore incorrect. So is the idea that a zvol can safely be resized online while remaining active swap merely because its storage size is adjustable. Swap layout and active use require their own controlled procedure.
For a ZFS host, review the distribution and OpenZFS guidance and the actual storage design. If a non-ZFS swap partition or other supported device is needed, plan it without overwriting pool members or data. This article deliberately does not present a destructive repartitioning shortcut as a routine fix.
If an existing zvol fails during boot, investigate the actual device, pool-import state, dependency ordering, and logs. Enabling two generic services does not prove that every installation’s ordering will be correct. The OpenZFS FAQ is the primary reference for the documented risk.
Swappiness is a reclaim preference, not a RAM-full trigger
vm.swappiness influences the relative preference for reclaiming anonymous memory versus filesystem-backed pages. It is not “the percentage of RAM at which swap begins.” Current Linux documentation describes a range up to 200, including values that can make sense when swap uses fast compressed memory.
There is no universally correct value of 10 for every server. The appropriate choice depends on storage, workload, caching behaviour, and the kernel. Measure the relevant latency and paging before and after a controlled change. Keep the original setting so the comparison is reversible.
cat /proc/sys/vm/swappiness
# Example of a temporary experiment, only after choosing it for the workload:
sudo sysctl vm.swappiness=20
Persist a chosen setting through the distribution’s supported sysctl configuration, avoiding conflicting entries in several files. Changing the preference does not instantly remove already swapped pages. Use the Linux kernel’s VM documentation for the parameter’s definition rather than interpreting it as a percentage threshold.
Remove or resize swap with a capacity check
Disabling swap may require moving its pages back into RAM or another swap device. Under pressure this can fail or severely disrupt a running workload. Do not use swapoff -a as a casual first step for changing one file: it targets all active swap.
Identify the exact target, establish sufficient capacity, plan the operation, and verify the result. Only after the chosen device is inactive should its file or storage configuration be replaced. Adjust the corresponding persistence entry deliberately. Do not remove a file because its name looks like swap without checking active use.
A useful verification record
Record the kernel/distribution, filesystem or device, swap size, active configuration, workload, and reclaim setting. Capture interval paging and the service latency that matters. A sequential disk benchmark is not a measurement of random page-fault latency, and a RAM-bandwidth-to-disk-bandwidth ratio is not a reliable prediction of application slowdown.
This turns a tuning change into an answerable question: did the workload become more resilient or responsive under the tested conditions? It also makes a later regression easier to distinguish from an unrelated workload change.
Questions readers often ask
Does used swap prove a memory leak?
No. Check active paging, available memory, workload history, and per-process evidence. A single amount is insufficient.
Does a zvol avoid ZFS swap deadlock?
No guarantee exists. OpenZFS explicitly documents the risk for zvol swap under memory pressure.
Does swappiness 10 mean swap starts at 90% RAM use?
No. It is not a memory-utilisation threshold.
Can NVMe swap replace RAM without noticeable effects?
Do not assume so. Page-fault latency and working-set behaviour matter, not just sequential throughput. Test the real workload.
Is one swap size right for all high-memory servers?
No. Capacity, latency requirements, peaks, compressed swap, hibernation, and software policy all affect the decision.
