How to Monitor Swap Usage on a Linux Server Before It Causes Problems

Your server is slow. SSH feels laggy, requests are timing out, and the logs are full of cryptic delays. You check CPU — fine. You check disk I/O — fine. Then you check memory and see it: swap usage is at 80% and climbing. By the time swap is doing heavy lifting, your application is already suffering. The trick is catching it before it gets there.

Why Swap Usage Is a Warning Sign, Not a Feature

Swap exists as a safety net — it lets the kernel move infrequently used memory pages to disk so active processes can keep running. That sounds helpful, but disk access (even on an NVMe SSD) is orders of magnitude slower than RAM. When your application starts hitting swap regularly, response times degrade visibly and unpredictably. Heavy swap activity — called thrashing — can make a server feel completely unresponsive even when it technically hasn't crashed. The OOM killer stepping in afterward is often the first obvious symptom teams notice, but the real damage happened minutes earlier.

The Commands You Actually Need

Start with the basics. The `free -h` command gives you a clean overview of physical memory and swap in human-readable units:

free -h Check the Swap row. If 'used' is anything above zero, something has been pushed out of RAM. If it's above 20–30% of total swap, dig deeper immediately.

For a real-time view of swap activity, `vmstat` is more useful than a one-shot snapshot. Run it with an interval to see what's actually happening over time:

vmstat 2 10 Watch the 'si' (swap in) and 'so' (swap out) columns. Non-zero values here mean active swapping is happening right now. Even small, persistent numbers are a red flag.

To find out which processes are responsible for swap consumption, use this one-liner that reads from `/proc`:

for pid in /proc/[0-9]*; do awk '/VmSwap/{print $2}' $pid/status 2>/dev/null | grep -v '^0$' | xargs -I{} echo "$pid: {} kB"; done | sort -t: -k2 -rn | head -20

This gives you a ranked list of which processes are sitting in swap, so you're not guessing. You can also use `smem` if it's available on your distro — `smem -s swap -r` does the same job with cleaner output.

Setting Thresholds That Actually Matter

Not all swap usage is equally alarming. Context matters. A baseline of a few hundred megabytes of swap in use on a server with 32 GB RAM might be harmless — the kernel sometimes moves cold pages proactively. What you're really watching for are trends and activity rates, not just absolute numbers.

• Swap used > 10% of total: worth noting, investigate if unexpected.
• Swap used > 25% of total: alert — memory pressure is real, find the cause.
• Swap used > 50% of total: urgent — performance is likely already degraded.
• si or so in vmstat consistently > 0: active swapping, fix this now regardless of percentage.
• Swap usage growing over hours without leveling off: a memory leak is probable.

The swappiness kernel parameter (`/proc/sys/vm/swappiness`, default 60) controls how aggressively the kernel offloads pages to swap. For application servers, lowering this to 10 or even 1 tells the kernel to exhaust RAM before touching swap. You can change it live with `sysctl vm.swappiness=10` and make it permanent in `/etc/sysctl.conf`.

Building a Simple Alerting Loop

If you're not running a full monitoring stack yet, a cron-based script can cover the basics. Drop something like this into your crontab to get an email when swap crosses a threshold:

#!/bin/bash SWAP_USED=$(free | awk '/Swap/{print $3}') SWAP_TOTAL=$(free | awk '/Swap/{print $2}') if [ "$SWAP_TOTAL" -gt 0 ]; then PCT=$((SWAP_USED * 100 / SWAP_TOTAL)) if [ "$PCT" -gt 25 ]; then echo "Swap at ${PCT}% on $(hostname)" | mail -s "Swap Alert" you@example.com fi fi

Run this every five minutes via cron. It's not sophisticated, but it will catch a swapping event before your users do. If you're already using Prometheus, the `node_exporter` exposes `node_memory_SwapFree_bytes` and `node_memory_SwapTotal_bytes` — build an alert rule off those instead, and add a second rule on `node_vmstat_pswpin` and `node_vmstat_pswpout` to catch active swapping even when absolute usage looks low.

What to Do When Swap Is Already High

If you arrive at a server mid-incident with high swap, your priority is identifying the offending process and deciding whether to kill it, restart it, or add RAM. Use the `/proc` loop above to find the top swap consumers. If you have headroom in physical RAM, you can also run `swapoff -a && swapon -a` to force all pages back into RAM — but only attempt this if `free -h` shows you have enough free memory to absorb them. Forcing a swapoff with insufficient free RAM will cause the OOM killer to start terminating processes, which is rarely what you want mid-incident.

Long term, persistent swap usage almost always signals one of three things: a process with a memory leak, a workload that has outgrown the server's RAM, or a misconfigured application allocating more than it needs. Solving the symptom by adding swap space just delays the reckoning.

If you want swap monitoring handled automatically without scripting it yourself, Opservo watches memory and swap trends continuously and will surface warnings in plain English before usage reaches a critical level — useful when you're running production without a dedicated ops person watching dashboards all day.

Either way, the core habit is the same: treat non-zero swap activity as a signal worth investigating, not a normal background condition. Catching it early — when you still have time to think — is the difference between a quiet fix and a 2 a.m. outage.

Invite the reader to connect their server to Opservo's free 2-server plan to get automatic swap and memory trend alerts without writing cron scripts. — one command installs a read-only agent and your first findings arrive in five minutes: start free. Related: guides why is my server slow.