Swap Full: Symptoms, Diagnosis & Fixes

Swap is the overflow tank for memory. When it runs dry too, the only thing left to spill is your processes.

What It Is

Swap is the disk that pretends to be RAM. When physical memory fills up, the kernel needs somewhere to put pages it can't keep in RAM right now, so it copies the least-recently-used ones out to a reserved slice of disk — a swap partition or a swap file — and frees the RAM they were holding. Those pages are still there, still part of a running program; they've just been parked on slow storage until something asks for them again. Swap is, in one line, the overflow tank: when the real tank (RAM) overflows, this is where it spills.

So "swap full" means both tanks are nearly empty of headroom — RAM is exhausted and the overflow you spilled into is itself almost gone. And that's the whole reason this page matters and isn't just a curiosity about disk usage: a full swap, on its own, is rarely the disease. It's the last warning light before the out-of-memory killer. When SwapFree is scraping zero and MemAvailable is too, the kernel has run out of places to put the next page — and the next thing it does is start killing processes to make room. Swap filling up is the smoke; the OOM killer is the fire, and it's usually minutes away.

Here's the nuance that catches almost everyone, though, and it's why this page exists instead of a one-liner that says "add RAM": some swap usage is completely healthy, and a non-zero Swap used is not, by itself, a problem. A Linux box that's been up for a month will happily have a few hundred megabytes in swap even with gigabytes of RAM free — because it parked some pages that genuinely were idle (a logging daemon that wrote one line at boot and went quiet) and spent the reclaimed RAM on something more useful, like disk cache. That's the kernel doing exactly its job. The skill this page teaches is telling that — swap as a sensible parking lot — apart from swap as a desperate, churning symptom of real memory pressure. The first is fine forever. The second is an outage with a countdown. By the end you'll read free -h, swapon --show, and /proc/meminfo well enough to know which one you're looking at, see exactly which process got swapped out, and know the four real fixes — none of which, spoiler, is "turn swap off."

How You Notice

Swap fills up loudly if you know where to listen, and silently if you don't. Here's each tell, with the command to check it on your own box right now — so you can separate a real squeeze from a harmless parking lot.

free -h shows the Swap line's free near zero. The blunt, first-look symptom. One command, the whole memory picture:
```
free -h
```
Read the Swap row: when its used is close to total and free is a sliver, the overflow tank is nearly full. But read the Mem row in the same glance — specifically the available column — because swap-full-with-RAM-available is a shrug, and swap-full-with-RAM-also-gone is an emergency. (Full reference on free; it's the first command on this whole page.)
Everything gets sluggish and the box feels like it's wading through mud. The classic feel of a memory squeeze. When RAM is full and the kernel is actively shuttling pages in and out of swap to keep going, every program that touches a swapped-out page has to wait for a disk read first — and disk is thousands of times slower than RAM. The CPU often looks idle in top while the box crawls, because nothing is computing; everything is waiting on disk. That sustained churn has its own name and its own page — swap thrashing — and it's the difference that matters most below.
OOM lines in the kernel log. The end of the road. When swap and RAM are both gone, the kernel's out-of-memory killer picks a process and shoots it. It narrates each kill in plain text:
```
dmesg -T | grep -iE "out of memory|killed process|oom"
journalctl -k -p err | grep -i oom
```
A line like Out of memory: Killed process 4123 (mysqld) total-vm:8123404kB means swap-full already graduated to out-of-memory. If you're seeing these, you're past warning and into damage.
A service mysteriously restarts or vanishes. The baffling register — how many people actually meet a full swap. Not by reading free, but by a database that "crashed," a worker that got reaped, a container that OOM-killed and restarted, all with nothing in the application's logs to explain it. The explanation is in the kernel's log, above: something was killed to reclaim memory. When a process dies for no reason it logged itself, check dmesg for the OOM killer before you suspect a bug.

Any one of these means the same first move: run free -h, read the Swap line and the Mem available column together, and read on. Swap used in isolation tells you almost nothing; swap used next to available RAM tells you everything.

How I Read It

The whole diagnosis starts with one command, and the art is reading two rows of it at the same time. Here's a real run from a moderately busy box, web-01:

free -h

               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       6.9Gi       181Mi       212Mi       640Mi       268Mi
Swap:          2.0Gi       1.9Gi        96Mi

It looks like six columns of numbers, but for this problem you read it like a pair of fuel gauges, top one first. Let me walk every column, because half of them are famously misread and the misreads are exactly what send people down the wrong path.

Mem → total (7.7Gi) and used (6.9Gi). The physical RAM in the box, and how much is currently spoken for. used here is high — but used is not the number you judge memory pressure by. That honour goes one column right.
Mem → available (268Mi). This is the single most important number on the page. It's the kernel's honest estimate of how much memory you could hand to a new program right now without swapping — and crucially, it already counts reclaimable cache as available, so you don't add anything to it. At 268Mi out of 7.7Gi, this box has almost nothing left. (CleverUptime's memory check judges off exactly this figure, not used — see memory full.)
Mem → buff/cache (640Mi). Memory the kernel is using for disk cache and buffers — and the number that fools everyone, because it counts as "used" in the old reckoning but is instantly reclaimable. The kernel keeps recently-read files in RAM because free RAM is wasted RAM; the moment a program needs that memory, the cache is dropped, no swap required. This is why "my RAM is 90% used" is usually fine — most of that 90% is cache the kernel will give back the instant it's asked. Here, though, it's already squeezed down to 640Mi, which tells you the pressure is real: the kernel has already evicted most of its cache and is still short.
Mem → shared (212Mi). Memory shared between processes — tmpfs, shared memory segments. Usually small; glance and move on, unless something's dumping gigabytes into /dev/shm.
Swap → total (2.0Gi), used (1.9Gi), free (96Mi). The overflow tank. 1.9Gi of 2.0Gi spilled into swap, 96Mi left. On its own that's alarming — but now read it in context of the line above it, which is the entire trick.

So here's the read, and it's a verdict, not a hedge: this box is in genuine, dangerous memory pressure. Not because swap is 95% full — that alone could be benign — but because swap is 95% full and available RAM is down to 268Mi and buff/cache has already been squeezed to the bone. All three gauges are on empty at once. There is nowhere left to put the next page. This is the shape of a box minutes from the OOM killer, and the honest next step is to find the memory hog now, not to admire the diagnosis.

Contrast that with the same Swap line on a healthy box:

               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       2.1Gi       1.2Gi       180Mi       4.4Gi       5.2Gi
Swap:          2.0Gi       384Mi       1.6Gi

Identical swap technology, completely different story. 384Mi is sitting in swap — but available RAM is a roomy 5.2Gi and buff/cache is a fat 4.4Gi. The kernel parked a few hundred megs of genuinely-idle pages weeks ago and spent the reclaimed RAM on cache. Nothing is under pressure; nothing is churning. This swap usage is healthy and you leave it alone. Same used value can be a crisis or a non-event — the deciding column is available, every time.

So burn in the one rule that survives this whole section: the number that matters for memory pressure is available, never used. The used column on the Mem line counts the reclaimable page cache as spoken-for, so a perfectly healthy server routinely shows 85–95% RAM "used" — that's the kernel doing its job, keeping hot files in fast memory. available already subtracts everything the kernel can hand back on demand, which is why it's the one figure that actually answers "am I about to run out?" Judge by available, and treat a scary-looking used the way you treat a scary SMART headline — read straight past it.

Where the Swap Lives, and How Full Each Is

free -h totals all your swap together. To see the actual swap devices — partition or file, how big, how full, and in what order the kernel uses them — there's a dedicated command:

swapon --show

NAME       TYPE       SIZE  USED  PRIO
/swapfile  file         2G  1.9G    -2

Four columns worth knowing. NAME is the device or file. TYPE tells you whether it's a raw partition or a file on an existing filesystem (a file is more flexible — you can resize it without repartitioning — and on modern kernels barely slower). SIZE and USED are this device's own totals. And PRIO (priority) decides the order: the kernel fills higher-priority swap first, and when two have equal priority it stripes across them like a poor man's RAID-0. A negative auto-assigned priority like -2 is the normal default. If you ever add a second, faster swap device (say, on NVMe), give it a higher priority so the kernel reaches for the fast one first.

What's Actually In Swap

free and swapon tell you how much is swapped; neither tells you what. For the question that actually leads to a fix — which process got pushed out to disk? — you read each process's own accounting. Every process exposes its swapped footprint as VmSwap in /proc/<pid>/status, and a one-line loop ranks them:

for f in /proc/*/status; do
  awk '/^Name/{n=$2} /^VmSwap/{print $2" kB\t"n}' "$f"
done | sort -rn | head

1605420 kB	mysqld
 487232 kB	java
  93180 kB	php-fpm
  41028 kB	containerd
   8704 kB	systemd-journal

Now the picture is concrete: mysqld alone has 1.5 GB sitting out on disk — it's both the biggest resident in RAM and the biggest thing that got spilled to swap. That's your culprit, named. (CleverUptime names the top memory consumer for you in the finding itself, so you often skip straight to this answer.)

Pro Tip

If you can install one tool, install smem (apt install smem) — it does the /proc walk for you and adds the column nobody else shows honestly: PSS (proportional set size), which divides shared memory fairly across the processes sharing it, so the numbers actually add up to reality. smem -s swap -r sorts every process by swap used, biggest first. The raw /proc loop above works on any box with nothing installed; smem is the comfortable version for when you can spare two minutes and a package.

For the raw source of truth — the numbers free is summarising — read the kernel's own ledger:

grep -i swap /proc/meminfo

SwapCached:        13936 kB
SwapTotal:       2097148 kB
SwapFree:          96024 kB

SwapTotal and SwapFree are exactly what they say (in kibibytes — divide by 1048576 for GB), and they're the fields CleverUptime's swap check reads to compute the percentage in its findings. The sleeper here is SwapCached: memory that was swapped out, then read back into RAM, but whose copy still lingers in swap too — so if it's evicted again it needn't be rewritten. It's a small efficiency, and a quiet sign that pages are moving both directions, which brings us to the one measurement that separates healthy swap from a crisis.

The Number That Actually Decides It: the Rate

Here's the deepest read on the page, the thing that turns "swap is 95% full" from a panic into a verdict. Raw swap used is a snapshot; what matters is the rate pages are moving in and out. A box can sit at 95% swap used for months, rock stable, because those pages were parked once and never touched again — that's the healthy parking lot. The danger sign is swap that's actively churning: pages streaming out (so) and back in (si) continuously, because the working set no longer fits in RAM and the kernel is frantically juggling. That's swap thrashing, and you see it in vmstat:

vmstat 1 5

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  2 1958400  92160  10240 640512  4096 6144 12300  6200 3100 8400  9  6  3 82  0
 2  3 1958400  88064  10240 638400  5120 7168 14100  5800 3300 9100 11  7  2 80  0

The two columns to stare at are si (swap-in, KB/s) and so (swap-out, KB/s). Idle parking lot: both sit at a flat 0. A box in trouble: both are non-zero and staying non-zero, like the 4096/6144 above — thousands of KB per second crossing the RAM↔disk boundary continuously. And look at the wa column: 82 — the CPU is 82% waiting on I/O, doing nothing useful, while the disk drowns under page traffic. That wa near the ceiling with si/so busy is thrashing, the unmistakable fingerprint of a box that has run out of real memory and is using its disk as a very slow, very sad extension of RAM. That's the emergency. High swap used with si/so at zero is just a tidy parking lot.

Reading It by Example

Train the pattern-match. Readout on the left, what I'd actually conclude on the right:

free -h: Swap 384Mi/2.0Gi used, Mem available 5.2Gi → Healthy parking lot. The kernel parked some idle pages and spent the RAM on cache. Nothing to do; leave it alone. By far the most common shape — most boxes with any uptime look like this.
Swap 1.9Gi/2.0Gi used, Mem available 268Mi, buff/cache squeezed to 640Mi → Real, dangerous pressure. Both tanks near empty, cache already evicted. Find the memory hog now (the /proc VmSwap loop or smem); you're minutes from the OOM killer.
vmstat 1 shows si/so flat at 0, swap 90% used → Stable. Pages parked long ago, never touched. The high number is harmless; the rate is what counts and the rate is zero.
vmstat 1 shows si/so both busy and wa near 80–90% → Swap thrashing. The working set no longer fits in RAM; the box is using disk as slow RAM and grinding. This is the live emergency even if swap isn't 100% yet.
dmesg shows Out of memory: Killed process → Already past warning — out-of-memory has fired. Swap and RAM both ran dry and the kernel started reaping. Find what's eating memory and fix the cause, not just the symptom.
Swap 0B/0B in free -h and the box is OOM-killing → There's no swap configured at all, so the moment RAM fills, the OOM killer fires instantly with no overflow buffer. Adding a modest swap file buys you a warning window — see the fixes below.
vm.swappiness is 100 and the box swaps eagerly with RAM to spare → The kernel's been told to prefer swapping over keeping pages in RAM. Not a memory shortage — a tuning choice gone wrong. See swappiness too high.

How to Fix It

The fixes split cleanly by what the diagnosis told you. If swap is full and available RAM is near zero, you have a real memory shortage and the ladder below is in priority order. If swap is full but RAM is fine and si/so are zero, you have nothing to fix — that's the parking lot, and the only mistake available to you is "fixing" it. First, the warning that turns a memory squeeze into lost data:

Danger

Do not "fix" swap pressure by running swapoff on a box that's already short on memory. To turn swap off, the kernel must first read every swapped page back into RAM — and if there isn't enough RAM to hold them (which, on a swap-full box, is precisely the situation), swapoff either hangs for ages thrashing the disk or triggers the OOM killer immediately, killing a process to make room. You'd be trading a survivable squeeze for a guaranteed kill. Free real memory first (find the hog, restart it, add RAM); only ever swapoff on a box with comfortable free RAM.

Then, by cause, easiest and most-targeted first:

Find and deal with the memory hog. Nine times in ten, swap-full-with-RAM-full is one process that ballooned — a leaking app, a database with an over-generous buffer pool, a runaway worker. Name it with the /proc VmSwap loop or smem -s swap -r above, confirm it in top (press M to sort by memory) or ps aux --sort=-%mem, then act on that process: restart it to reclaim a leak, lower its memory limit, or fix the config that let it grow. A memory leak in particular won't be cured by more RAM — it'll just take longer to fill. (If it climbs back after a restart, that's a memory leak, a different page.)
Add RAM. The honest fix when the workload genuinely needs more memory than the box has. Swap is not a substitute for RAM — it's a slow safety margin — so a server that lives in swap is a server that's under-provisioned, and the right answer is more physical (or, on a cloud instance, virtual) memory. Everything else on this list buys time; this removes the cause.
Right-size or add swap. If you have no swap (free -h shows Swap 0B), add a modest swap file so the OOM killer has a warning buffer instead of firing the instant RAM fills — a few commands, no reboot:
```
fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
```
Then add it to /etc/fstab so it survives a reboot. The right size is a judgement call, not a ritual: the old "2× RAM" rule is long dead for big servers — a 64 GB box does not want 128 GB of swap. A few GB is plenty as an overflow buffer; if you find yourself wanting lots of swap, what you actually want is more RAM.
Tune swappiness. If the box swaps eagerly while RAM is plentiful, the kernel's vm.swappiness knob (0–100, how willingly it swaps idle pages out) may be set too high. Check and lower it:
```
cat /proc/sys/vm/swappiness
sysctl -w vm.swappiness=10
```
Make it permanent in /etc/sysctl.d/. For most servers 10 is a sane value — keep more pages in RAM, swap only under real pressure. This treats eager swapping, not a genuine shortage; the full story is on swappiness too high.

Pro Tip

On a box that's already thrashing too hard to even log in cleanly, earlyoom is the kindest tool in the box. It's a tiny userspace daemon that watches free memory and free swap and kills the biggest hog gracefully the moment they cross a threshold — before the kernel's own OOM killer kicks in mid-thrash, which can leave a box frozen and unreachable for minutes while it grinds. Install it, set a threshold, and a memory runaway becomes one quick process death instead of a ten-minute hang. It's the seatbelt for exactly the situation this page describes.

How to Avoid It

A full swap is mostly preventable, because unlike a dying disk it doesn't arrive at the speed of physics — it arrives at the speed of your workload's memory appetite, and that's something you can stay ahead of. In rough order of payoff:

Watch the trend, not the snapshot. Swap at 60% means nothing on its own; swap that climbed 10% → 60% over a week, while available RAM fell in step, is an outage with a date on it. The single most useful thing is knowing the rate memory is tightening — because a box gaining a little swap a day has a runway you can plan around, while a box gaining it an hour is tonight's problem. A human glancing at free by hand always checks the morning after the OOM kill.
Right-size the box for its working set. Swap exists to absorb spikes and park genuinely-idle pages, not to be a permanent extension of RAM. If a server lives with si/so regularly non-zero, it doesn't have enough RAM for what it runs — add memory or move some load off. A server should touch swap rarely, not constantly.
Cap the greedy services. Databases, JVMs, and caches will happily take all the RAM you let them and then some. Give them explicit memory limits (MySQL's buffer pool, the JVM's -Xmx, a container's --memory) sized to leave the OS real headroom, so one service can't quietly squeeze everything else into swap.
Set vm.swappiness deliberately, not by accident. Most servers want a low value (around 10) so the kernel keeps the working set in RAM and reaches for swap only under genuine pressure. Leaving it at a high default makes the box swap eagerly and feel slow for no good reason — the avoidable cousin of this whole page, covered on swappiness too high.

Note

The temptation, when swap keeps filling, is to add more swap — and it's usually the wrong instinct. More swap doesn't add memory; it just adds more slow disk for an already-overcommitted box to thrash against, turning a quick OOM kill into a long, miserable grind. If a server genuinely needs more memory, the cure is RAM, not a bigger swap file. Swap is a safety margin and a parking lot — size it sensibly and stop. "We need more swap" is the reflex; "what's eating the RAM?" is the cure.

How Swap Actually Works

Now the part you don't need mid-emergency but that turns this page from a checklist into an instinct: why does the kernel swap at all, why is some swap healthy, and why does a full swap end in the OOM killer? It all comes down to one of the most elegant ideas in operating systems — virtual memory — and once you see the machinery, every symptom above becomes something you can simply reason out.

Every Program Lives in a Beautiful Lie

No program on your server has ever touched a real byte of RAM directly. When a process asks for memory, the kernel hands it addresses in a private, imaginary address space — virtual memory — that the process believes is a vast, contiguous expanse all its own. Behind the scenes, the kernel and a chip called the MMU (memory management unit) maintain a translation table — the page table — that maps each virtual page (a 4 KB chunk) to wherever its data physically lives. The program never knows or cares where that is. It just reads address 0x7f...; the hardware quietly translates that to physical RAM frame number whatever, on every single memory access, billions of times a second. This indirection is the foundation everything else rests on: it's why two programs can both think they own address 0x400000 without colliding, why a process can't read another's memory, and — the part that matters here — why a page's data doesn't have to be in RAM at all.

Because here's the trick the page table makes possible: a virtual page can map to a physical RAM frame, or it can be marked "not present, currently on disk in swap." When a program touches a page that's been swapped out, the MMU finds the "not present" mark and raises a page fault — a tiny hardware interrupt that hands control to the kernel. The kernel sees "ah, this page is in swap," finds a free RAM frame (evicting something else to swap if it must), reads the page back in from disk, updates the page table to point at the new frame, and resumes the program exactly where it left off. The program never knew it happened — except that the instruction that touched that address took a few milliseconds instead of a few nanoseconds, because a disk read stood in for a memory read. That single page fault, multiplied by thousands per second, is the sluggishness of a swapping box. The lie is seamless; it's just slow when the truth lives on disk.

Why Some Swap Is Not Just Fine, but Smart

Now the healthy-parking-lot mystery dissolves. The kernel's job isn't to keep RAM empty — empty RAM is wasted RAM. Its job is to keep RAM useful. So it makes a constant, sensible trade: if a page hasn't been touched in ages (that logging daemon's startup code, a config parser that ran once at boot and went quiet forever), why let it squat in precious fast RAM? Swap it out to disk, and spend the reclaimed frame on something with a payoff — page cache for the files you're actually reading, buffers for the I/O you're actually doing. The idle page sits harmlessly in swap, costing nothing, and if it's never touched again (the common case), that disk read to bring it back never happens. You got free RAM for cache in exchange for pages you weren't using anyway. That's why a healthy box has swap used and zero si/so traffic: the kernel made a smart trade once and the parked pages never had to come back. Swapping out is cheap insurance; only swapping in, repeatedly, is the cost — which is exactly why the rate, not the total, is the number that matters.

The vm.swappiness knob is simply how aggressively you let the kernel make that trade. At 0 it clings to anonymous pages in RAM and only swaps as a last resort; at 100 it swaps idle pages out eagerly to maximise cache. The default sits in the middle, and for most servers a low value is right — your working set is hot, you'd rather keep it in RAM than gamble on the kernel's idea of "idle." Tune it knowingly; that's swappiness too high when it's set wrong.

Overcommit, Thrashing, and the Cliff at the End

So if swapping is so clever, why does it end in disaster? Two reasons that compound.

First, overcommit. Linux hands out more virtual memory than it physically has, betting that programs reserve far more than they touch — and the bet usually pays. But "usually" is load-bearing. When programs actually use what they reserved and the sum exceeds RAM, the kernel leans on swap to honour the promise. Swap is the slack that makes overcommit safe… right up until the slack runs out.

Second, thrashing, and it has a cliff-edge quality that's worth understanding. As long as the active working set — the pages programs are actually touching moment to moment — fits in RAM, swap holds only idle pages and life is good. But push the working set past RAM, and the kernel is forced to swap out pages that are still in use. Now program A touches its page, faulting in from disk and evicting program B's page; a microsecond later program B touches its page, faulting it back in and evicting A's. The box spends all its time shuttling pages across the slow disk and almost none actually computing — wa pins near 100%, throughput collapses, and the machine that looked "idle" in top is in fact working desperately hard at the one thing that produces no results. That's thrashing, and it doesn't degrade gracefully; it falls off a cliff, because each swap-in forces another swap-out in a vicious spiral. (Its own page: swap thrashing.)

And then the bottom of the cliff: the OOM killer. When RAM is full, swap is full, and a program demands one more page the kernel can't conjure, the lie finally cannot be maintained — there is no frame, real or on disk, to hand over. The kernel's last resort is brutal and deliberate: it scores every process by a heuristic (roughly, how much memory it's using weighted by an adjustable oom_score_adj), picks the "worst" offender, and kills it outright to reclaim its memory. No clean shutdown, no warning to the app — just a SIGKILL and a terse line in dmesg. This is by design: a Linux box would rather sacrifice one process than freeze entirely, and the OOM killer is the mechanism that keeps the rest of the system alive. But it means swap-full isn't a stable state you can sit in — it's the last rung before the kernel starts shooting. (The whole drama of who gets picked and why is its own page: out-of-memory.)

So hold the whole arc in your head and the page reads itself: virtual memory lets every page live in RAM or on disk; the kernel swaps idle pages out as a smart trade (healthy swap, zero churn); push the working set past RAM and that trade turns into a thrashing spiral (the real emergency, measured by rate); fill swap too and overcommit's bill comes due in the form of the OOM killer. The kernel keeps an honest ledger of all of it in /proc/meminfo — but a ledger only ever buys you warning, and warning is worth nothing if nobody reads it until the morning after the kill.