You’re staring at a frozen terminal. The cursor blinks once, then stops. Your heart sinks—the OOM killer is coming. Or worse, the system just hangs for thirty seconds every time you open a browser tab. Which pain do you choose?
If you’ve ever tweaked swap on Linux, you know this dance. Everyone has an opinion: “Disable it completely—swap kills performance!” or “Always set it to 2x RAM—it’s a safety net!” Both camps are wrong, and they’re fighting a battle that modern hardware already won.
Swap isn’t evil. Your old thinking is.
Let’s rewind. For decades, HDDs were the norm. Swap on a spinning disk meant your system turned into a laggy mess the second it touched paged memory. So the standard advice made sense: avoid swap like the plague, or at least keep it tiny. But that advice is a relic—like using a floppy disk to hold your SSH keys.
Today, most Linux machines—servers, desktops, even some embedded devices—boot from NVMe or SATA SSDs. Random read/write latency dropped from ~10ms (HDD) to ~0.1ms (SSD). That’s two orders of magnitude. Suddenly, swap doesn’t feel like a punishment. It feels like a safety net that barely slows you down.
I learned this the hard way. I had a production server with 32GB of RAM and a tiny swap partition (2GB) on a fast SSD. During a memory spike, it hit swap hard—and barely noticed. The app stayed responsive. The same workload on an HDD would have collapsed under its own weight. That’s when I realized: the real variable isn’t whether you enable swap, but what you put it on.
So what’s the actual trade-off? Every byte written to swap is a byte you didn’t have to evict from RAM. The cost is disk I/O—which on an SSD is cheap, but not free. The benefit is avoiding an out-of-memory kill, which is catastrophic for uptime and user experience. In most modern workloads, the benefit outweighs the cost—especially if you tune the swappiness parameter.
Here’s the twist: most Linux users still set vm.swappiness=60 (the default) or blindly follow the old 2x RAM rule. Both are mistakes. The default swappiness was tuned for HDDs, where the kernel eagerly avoids swap. On SSDs, you can safely increase it—say, to 80 or even 100—and let the kernel use swap more aggressively as a primary overflow, not a last resort. The result? Fewer OOM kills, smoother memory pressure handling, and no perceptible slowdown.
Stop treating swap like a backup plan. Treat it like a pressure release valve—one that works perfectly fine on modern hardware.
But there’s a catch: over-provisioning swap can backfire. If you allocate swap that’s too large (say, 16GB on a 8GB RAM system), you risk the kernel paging out rarely-used code paths, only to reload them seconds later—thrashing, even on an SSD. The sweet spot? Roughly 1x to 1.5x your RAM, capped at 8-16GB for most desktops. For servers with predictable workloads, match swap to your expected peak memory overhead.
I’ll give you a concrete rule: on any Linux system with an SSD, set vm.swappiness=100 and swap size = RAM size (or 8GB, whichever is smaller). Then monitor sar -S for swap activity. If you see more than 10% of pages swapped in a minute, dial swappiness back to 80. If you never hit swap, consider lowering the size to save disk space. This isn’t dogma—it’s a tuning strategy that adapts to your actual behavior.
Still think swap is useless? Consider this: I’ve seen a 4GB Raspberry Pi run Docker containers smoothly with 4GB of swap on an SD card. The SD card is slow—but the alternative was crashing every hour. Swap is the difference between a system that degrades gracefully and one that dies suddenly.
The real enemy isn’t swap. It’s ignorance of your hardware. If you’re running an HDD, yes, minimize swap. But if you’re on an SSD—and you almost certainly are—stop parroting advice from a decade ago. Your Linux machine deserves better than outdated heuristics.
So here’s my challenge: next time you set up a Linux box, don’t disable swap. Don’t copy-paste some ancient forum post. Measure your I/O latency, test your workloads, and tune swappiness like a real engineer. Your future self—the one staring at a frozen terminal—will thank you.
FAQ
Q: Isn't swap always slower than RAM? Why not just buy more RAM?
A: Yes, swap is always slower. But more RAM costs money and can't be added to every system (especially embedded or cloud instances). Swap is a zero-cost safety net that prevents catastrophic crashes when memory pressure spikes. On SSDs, the performance penalty is negligible during bursts—and far better than an OOM kill.
Q: What's the practical implication for my daily Linux desktop?
A: Set swap size equal to your RAM (or 8GB if you have more), swappiness to 100, and use an SSD. You'll avoid freezes from memory-hungry apps (like browsers with 50 tabs). Monitor with `sar -S` and dial down swappiness only if you see heavy swap traffic. This gives you crash protection without noticeable lag.
Q: What's the contrarian take on swap?
A: The contrarian take: swap should be treated as a *primary* overflow on modern SSDs, not a last resort. By increasing swappiness to 100, you let the kernel proactively move cold pages to swap, keeping RAM free for hot data. This reduces out-of-memory kills and can actually *improve* overall responsiveness under pressure—exactly the opposite of the old 'disable swap' dogma.