Linux Performance: Why You Should Almost Always Add Swap Space

There is no worry putting swap on SSD.

Given the choice, you should prefer swap on SSD (since it's so much faster than spinny disks).

If swap on SSD was a bad idea, do you honestly think every laptop, desktop, and server manufacturer that uses exclusively SSD would still enable swap?

Every mainstream OS wants/needs swap - it helps all of them

But nice try at deflecting your lack of understanding.

I wrote a kernel from scratch, besides that I did quite a bit of transaction oriented stuff and built the server side of a very successful messaging platform. That does not make me an expert either but I do have some minimal understanding of what goes on under the hood. If you are simply configuring swap space on a better-safe-than-sorry basis then I would rather not have you near a system whose response has to be deterministic because it almost certainly will fail in some unpredictable way sooner rather than later.

Yes it is difficult stuff, no you do not get a free pass just because you messed with important stuff on a duct-tape-and-glue basis. See, swap is just a stay of execution, once a system starts swapping it is as good as out of control anyway so in the vast majority of cases that I am familiar with you want that situation to announce itself loud and clear and in a way that gives you back control. You then do postmortem and you fix it so it will not happen again. That is far preferably over having systems that remain partially broken but pretend to be fine.

I know plenty of people run after each other claiming great insight by quoting the various help-yourself sites but it amounts to absolutely nothing when you suddenly find yourself trying to figure out why your transaction queues are overflowing because some system in the pipe suddenly decided 100ms is as good as 10 as long as things keep flowing.

If on the other hand your systems are not important enough to properly set them up with static resources committed to long running processes and with strict limits on what logged in users can do from the command line then this advise is going to fall on deaf ears because you did not need reliability in the first place. Note that in many business context latency is far more important than throughput.

This risk is hugely overstated for most use cases based on people having 'baggage' from 'dumb' flash memory cards.

eMMC is another story (because these are basically 'dumb' flash memory cards)

Recently read an article by samsung where they claim that 3d nand SSD drives can handle ~1x full drive write per day (e.g. 1TB drive -> 1TB/day) and still last the rated lifetime, and that v-nand can handle something like 5-10x (don't remember off hand precice figures, but it was easily googlable). Yes, this is a vendor figure - but should be at least ballpark accurate I'd think.

Also, many SMART-capable drives show their estimated write cycle lifetime in SMART status (again, vendor figure, but still) .. if you check this on your laptop I bet you will be surprised at how low the figure is.

All you need to do is to monitor your memory usage, any growth that you do not understand is a reason to stop what you are doing immediately and to figure out what is going on.

A few GB extra swap space will not save your bacon, will make it much harder to get the system back under control because it is no longer responsive compared to a process killed with a supervisory process restarting that process immediately and logging a fault.

And if your systems can't handle that you have bigger problems, likely you then also won't be able to deal with hardware faults, crashes, power failures and other errors.

A postmortem is far preferable when it is about a process that is re-launched in a small fraction of a second after which the system is back to normal if the alternative is a system that causes a whole cascade of stuff to go out of whack down the line.

Pretty much only Erlang/OTP get this sort of thing right to begin with.

Errors - including out of memory errors - should be expected and should be dealt with in a deterministic manner.