I wondered this for a while, unfortunately a major question I have remains unanswered in the text: What about SSDs and SSD-only systems? (Like... any average laptop.) Should I be worried that putting a swap on an SSD will cause it to wear out fast due to many write cycles?
I've swapped hundreds of terabytes to consumer SSDs. Haven't noticed any problems yet (visibly).
By the time you start to see r/w issues on anything that resembles a modern SSD, you're probably wanting to replace the overall device anyway
Cargo cult system administration. No, you should not 'almost always add swap space'. What you should do instead is tune your system for its intended use. If you need swap as an 'early warning system' that you're about to run out of memory you're already doing it wrong and the OOM killer is a piece of code that has default settings that can be tuned, ditto for the virtual memory manager in the kernel. http://www.oracl…
You should just about always add at least some swap.
Anyone who thinks otherwise hasn't read much or seen very many systems.
I've been in environments ranging from a few dozen individual servers to 100s of 1000s. In companies ranging from mom-and-pop shops to international investment banks. Every last one is configured with swap. Because unless you have done all the profiling to truly know you don't need it, you should be running it.
I used to work in flash manufacturing. We would joke, "I hope nobody ever uses this for swap!" The numbers I saw for endurance (basically write-erase cycles before failure) were not encouraging at all. As far as I can tell the only reason MLC flash works at all is that the controller does some magic to present a whole bunch of pretty flaky cells as a single reliable unit.
>I used to work in flash manufacturing How long ago? r/w cycles haven't really been an issue on SSDs in a long time
2010. I've been following the industry since I left, and I promise you neither the physics of FN flash nor the manufacturing process has fundamentally changed since then. Nor have the true endurance numbers substantially improved. If anything the situation is worse now with smaller device dimensions. The only thing standing between your collection of cat gifs and oblivion is the flash controller making intelligent guesses about what it just read.
> As a last resort, the Kernel will deploy OOM killer to nuke high-memory process(es) Yes! That is exactly what I want to happen! When the system runs out of RAM, things will generally stop functioning, swap enabled or not. The only question is how you want it to stop functioning when that happens. In almost every situation, I'll easily take the kernel killing whatever single process it thinks is most appropriate to…
Nowadays linux has this thing called zram disk. It compresses data in memory on the fly. I think general swapping advice would serve most people better if they always add swap on zram first, before swap on ssd or hdd. The difference is that getting data in and out of zram is so fast that you can actually use it as a tier of a slower ram, transparently compressed.
I'm not going to disagree with the article, because I haven't done any testing myself that would suggest that the point made are wrong. I do however find it amusing to login to a system with 32 or 64GB of memory with a 2GB swap. It seems humorous that those 2GB should somehow do anything if you already used 64GB of RAM.
I can save you a bunch of testing time. Just enable swap (I typically peak at 34GB, but follow the `RAM + 2GB` rule-of-thumb before that
If you must use swap (you probably don't need to), then at least set zswap.enabled=1 in the kernel boot options, typically in grub. This will enable lzo compression of swap in memory so there is less writing to disk. Some newer kernels use lz4. Either way, what most folks are actually missing is the correct kernel settings for the amount of memory they have. Sadly, the kernel does not dynamically adjust these based o…