Almost Always Add Swap Space

I know I'm giving up some RAM that could be swapped out without impact but it's worth the stability of never swapping to an attached drive.

Windows would happily grow the pagefile beyond the limits I had set, and if the allocation loop was tight enough the OS chocked on handling all page faults. As in using literally minutes to respond to keystrokes.

By putting swap on a slow HDD, Windows has plenty of time to service mouse and keyboard input while waiting for the disk to respond, allowing me to kill the offending application before saturating my disk.

I assume this behavior was OK back when computers had very limited memory, and disks were slow anyway. But these days, if a single application wants more than the available memory (physical + pagefile), I'd rather the OS just said no to the application.

You can adjust "swappiness" if it's moving stuff to disk too aggressively.

The memory freed from a page that got pushed to swap might be better used for serving disk cache, for example.

If you don't have enough RAM (even for spikes), a preemptive push when things aren't busy might mean that when they do become busy, you won't have to wait.

At least, that's the theory as I understand it. Whether or not it works in practice, IDK.

> And using swap as some kind of "RAM emergency cover" does not make any sense to me. Personally, I have never had a case where I could gracefully recover a host that had started swapping.

I have successfully recovered hosts that began swapping, and even hosts that filled their swap. But it's beyond painful, and in most of the cases where I have a host doing such swapping, an OOM kill would have been a welcome reprieve.

> Second, I find it's much harder to detect degraded performance than it is to detect a dead process.

Agreed, and restarting something that's been OOM'd is simple enough too. Our hosts tend to stop reporting metrics when they start swapping, simply b/c so little is actually getting done, so they get labelled as "down". Linux also exposes a metric called "major page faults" (IIRC, it's "pgmajfault" in /proc/vmstat) that records the number of major (required service from disk) page faults; if the rate of that value is too steep for too long, that ≅ swap thrashing.

Putting rarely used (or never to be used again) pages in swap frees up physical RAM to be used as disk cache, which can improve performance for file access. If you have enough RAM to cover all application memory, and cache your entire filesystem, there is no gain to be had.

I agree that slowing down low memory scenarios is silly though. In many cases killing a process is easier to deal with than unexpected poor performance. The slow death of out of memory systems doesn't seem to be unique to having a swapfile though; Linux seems to discard any recoverable pages (such as application / library code backed by files on disc) in the run-up to OOM, resulting in thrashing.

Ideally I'd want to have swap, but automatically kill processes when performance deteriorates due to swapping, rather than when the system is strictly out of memory.

One thing I think the author was getting at, but never explicitly stated is that we spec most things for the average expected workload with a bit of headroom--not the peak workload since that is very difficult to assess. Peak workload might also be few and far between and not worth paying for upfront. Swap allows you to deal with peak workloads more gracefully for many applications.

Having your process randomly die isn't a big deal with stateless processes (which is a more and more common design), but really sucks for stateful things. Not just the possibility of lost/corrupt state, but process startup and loading of state can take a long time.

We have a few servers that don't have swap and I was hoping to find an excuse to add it in this article. Instead, it reenforced that decision because of type of things we run on it.

Using swap space may make sense for a traditional physical, stand-alone server, where having it fail quickly doesn't really help. Or maybe for a workstation.

The theoretical worst case scenario is that the system hits an OOM situation and you end up with data/filesystem corruption... I have not had this occur due to swap being turned off this century.[1] The typical worst case scenario is that either due to a runaway process or accidentally overloading the system for a indefinite period of time, the system goes completely unresponsive so you have to perform a hard reboot. This happens to me 1-2 times a year but I have yet to loose any data (and if it ever does, that's one of the many reasons to have backups) The more common scenario is that a runaway process will OOM briefly, when it can't allocate the memory it needs crash, and everything is back to normal within a couple of seconds.[2]

FWIW, mobile (Android and iOS) devices typically run without swap just fine. IMO, this 'always enable swap' is bad advice and dates from a time when very bad things could and did happen if you OOM'd a system. The marginal performance improvement from freeing up on the order of megabytes (or even tens of megabytes) of RAM on a system with double digit GB's of RAM makes absolutely no sense to me. It makes even less sense on SSD systems where you would be unlikely to notice a chronic swapping situation until you had severely shortened the life of your SSD.

[1] This would be a good reason to not turn off swap on a production database server where it is more likely to be an issue, for example.

[2] One of the dubious advantages to 'modern' programs not handling errors like OOM is that, since they don't check for it, they can't handle when it happens and just crash. This was actually more of a problem in the 90's and earlier when it was more common for applications to handle OOM situations which could actually make the problem worse since they would often hang around waiting for any memory to be freed and use it which resulted in a persistent OOM situation.

I'd suggest trying it and seeing what happens, if you wish to learn rather than listen to people who aren't using your host - and don't know what you run..

In a Microsoft OS? Depends on the app -- some are dependent (many games) on having swap available (and may err silently or under false pretenses without one).

I've found that a lot of MMO style games include cheat detection systems (see : rootkit) that rely on swap, and fail without it. As to why they do that, i'm unsure.

If memory pressure is low, and the swap is used to page out rarely / never used pages in favour of more disk cache, then there is a performance gain to be had, and wear should be minimal.

You can encrypt swap with a randomly generated key to aid security.

Ideally memory compression and disk swap would be used together; there's a gain to be had by shrinking lesser used pages, but no sense in taking up any space in RAM for pages showing no sign of life.

In my experience, when Chrome is being a memory hog I can swap about 2/3 of its memory out with zero performance impact. As long as I can swap that away, I never run out of memory. If I can't swap it to disk, I have problems. I don't think that qualifies as "too little ram".

So in this case performance is fine, security should be an issue of encryption not disabling, and the SSD is not going to wear out because of an extra <1% average utilization.

What you really want is to never have a severe out of memory situation, and you can do that either by getting enough RAM that you never use it all, or by killing stuff nice and early when memory starts getting low.