Linux: to swap or not to swap?

[shapirus]

OK, thank you.  To rephrase the question, if I have no swap, my 32GB RAM desktop goes belly up if somehow it runs out of RAM, right?

The OOM killer will kick in and kill the process which it considers the trouble maker.

Same will do if I have only 30 GB RAM + 2GB swap, right?

Yes, except that the OOM killer will kick in a little bit later, because it will take slightly longer to run out of memory, because disk-backed swap is slower than RAM.

Are there any hidden advantages, or maybe hidden needs for the OS, to keep a swap as long as I only use half of RAM?

No.

Do I have to have a swap if the physical RAM is plenty?

No.

In addition, there's a curious fact that some software even refuse to run if swap is enabled on the system (e.g., kubernetes).

Is the swap needed because it extends the amount of RAM

Yes. Historically it was invented to allow the processes to allocate and use more memory than the amount of physical RAM without spending crazy money on additional memory modules at the expense of performance (disk-based swap is much slower).

I can imagine a use case, probably not too realistic, where having swap would be beneficial, in which two conditions are true:

- there is a process (or multiple processes) which need to use a lot of memory, but the data in that memory is accessed very infrequently;
- there is very intensive disk read access taking place, especially when the disk is slow.

In this case, it may be desirable to enable swap to allow the kernel to move rarely accessed memory pages into swap to free up as much RAM as possible for buffers/cache.

or is it also needed because it will help the OS fail graciously (vs an allegedly sudden fail when the OS only has RAM)?

There is (usually) no OS failure in the OOM situation. The OOM killer gets rid of the processes that it considers to be resource abusers and whatever is left continues normal operation. It's the total amount of memory that counts, not the type of it, save for the disk vs RAM speed that I mentioned above.

[RoGeorge]

if it actually runs out, which means all file cache has been evicted and there's nothing left for the kernel to reclaim. Then it will invoke the OOM killer, which will choose a process to kill, in order to make more memory available. If swap is available, then the same situation will lead to thrashing as active pages are swapped on and off disk as they are needed, which can make the system barely usable.

That's the bird eye view I was looking for.  Thank you.  Since I was asking for a home desktop, I'll prefer a sudden fail rather than disk trashing, especially trashing with a silent SSD.

[SiliconWizard]

Just thinking, you can buy a small HDD and use it only as swap device and temp files.

Partition1 swap
Partition2 temp

It will make long life and prosper for your SSD.

What did I say just above?
I was mentioning a "small" SSD instead though, as they have become quite cheap, will still provide much better performance when accessed, and if it wears out, it's absolutely no big deal.

[DiTBho]

Just thinking, you can buy a small HDD and use it only as swap device and temp files.

Partition1 swap
Partition2 temp

It will make long life and prosper for your SSD.

What did I say just above?
I was mentioning a "small" SSD instead though, as they have become quite cheap, will still provide much better performance when accessed, and if it wears out, it's absolutely no big deal.

You said, since it's cheap so if it wears out, it's absolutely no big deal, I say ... ummm

My opinion, but "small" SSDs can be as cheap as you like and still will die if used for continuous I/O, while HDDs are also getting cheap and work better for that purpose.

Inferior performance? Yes SSDs are faster, and HDDs are fast enough, then, it depends on your purpose, for me, the best I can do is hybrid storage

• SSD -> RO, to load programs libraries, making it writable only on specific occasions (e.g. system update)
• HDD -> RW, to process stuff that need temporary storage + swap partition

Or, at least have the foresight to use two SSDs: one for the operating system, one for temporary files

• SSD#0 -> RO, to load programs libraries, making it writable only on specific occasions (e.g. system update)
• SSD#1 -> RW, to process stuff that need temporary storage + swap partition (cheap and easy replaceable)

so when SSD#1 dies ... only the latter dies and you don't have to rush to restore the system.

What I meant 

[rdl]

Just like flash drives, memory cards, etc., there's a manufacturing cost overhead that can't be avoided, so the smallest and cheapest you can buy constantly increases in capacity. And there is little savings in going small.

[SiliconWizard]

@DiTBho: I get it, this is just debatable. If you want a super long-term operating of your system without any hardware change, I agree. The HDD will (usually) win. My point here was that, for this use case where performance may still matter, but the data itself is temporary and non-critical, using a cheap SSD and having to change it every couple years looks like a pretty workable solution while not sacrificing anything.

But obviously it's 100% up to each individual situation.

[golden_labels]

OK, thank you.  To rephrase the question, if I have no swap, my 32GB RAM desktop goes belly up if somehow it runs out of RAM, right?  Same will do if I have only 30 GB RAM + 2GB swap, right?  For my desktop usage 30 or 32 GB is the same, never run out of RAM so far.

Others have already responded to the question directly, but let me make an important note here. Do not be focused too much on swap being 2 GB. If you used some wizard, don’t seek any deeper logic behind the choice of 2 GB. Doubtful there is any: there isn’t many choices. An arbitrary value, a result of some ancient or unfounded trade lore, or — though I admit I personally never heard about anything doing this⁽¹⁾ — an outcome of a statistical research (“fits most users”). The problem, which a wizard can’t overcome, is is that the amount of swap needed is tightly bound to your particular workload and whether you use hibernation.

In the distant past there were two “common knowledge” approaches. One was “as much as RAM”, the other “2× RAM size”. One comes from Microsoft Windows; the source of the other is more obscure, but appears to be somewhat related to enterprise usage of Linux. Both are ancient, devised when 4GiB RAM was nerds’ wet dream, and the Windows one is specifically bound to “swap is an emergency RAM” approach.

In my opinion the sanest approaches are:

• A blind one:⁽²⁾ just set swap to “a few gigs”. That may be not suitable for hibernation, if you have 32 GiB RAM. But otherwise: basically “just works”, doesn’t waste too much disk space in case you were wrong, in case of a catastrophic memory leak this size is bearable.
• If not using hibernation: the typical value you get from “Used” column in free -h. The reasoning behind is, that it gives the system an opportunity to push everything out of RAM. Which should (and will) never happen, but this is a ballpark estimate.
• If using hibernation: choose the percentage of cases in which hibernation should not fail and set swap to the corresponding percentile of memory used (as above, from free -h). The reasoning behind this is: it will provide enough space for hibernation to work. There are a few more factors to consider, than memory used, but typically they are countered by data being compressed for hibernation.

The latter two options should not be taken with religious rigour. I see them more as bringing focus to the most important factors than being a direct advice.

But I truly believe that, with systems offering that much RAM, we are at the time in which even above suggestions are becoming obsolete. And we need time to develop new ones.

Is the swap needed because it extends the amount of RAM, or is it also needed because it will help the OS fail graciously (vs an allegedly sudden fail when the OS only has RAM)?

Neither. For the first part see my post above. For the second: if an OOM condition occurs due to a runaway memory leak, this is a catastrophe one way or the other. The presence of swap doesn’t make it graceful. Quite opposite: the system gets blocked completely for a long time. This can be addressed with suitable cgroup settings for services and/or daemons like earlyoom or systemd-oomd. But with these in use the entire question becomes moot.

⁽¹⁾ I suspect I came across a few choices/guides, where this was the case, but this is merely my suspicion. No evidence. So I assume I never met with that.
⁽²⁾ I know, that in the tech crowd there is a strong tendency to make decisions, which at least give a feeling of being taken thoughtfully. But that has its drawbacks too: internal bikesheding and magical thinking. Sometimes it’s better to not have any technical reason, than being trapped into wasting time on following advice which only pretends to offer solid logic.

[DiTBho]

In the distant past there were two “common knowledge” approaches. One was “as much as RAM”, the other “2× RAM size”. One comes from Microsoft Windows; the source of the other is more obscure, but appears to be somewhat related to enterprise usage of Linux. Both are ancient, devised when 4GiB RAM was nerds’ wet dream, and the Windows one is specifically bound to “swap is an emergency RAM” approach.

that rule
         with k = { 0.0, 0.1, 0.2, ... 1.0, 1.1, 1.2, ... 2.0, 2.1, .... n }
         swap.size = k x ram.size
was/is an empiric approach based on statistical analysis.

my PPC-7550 cannot address more than 2GB of ram, the kernel is 32bit and cannot allocate more than 512Mbyte of stack per process.

At the moment the PSU is dead and i'm still trying to figure out how to fix it, during its golden ages it usually spent its time at compiling stuff, from the development of custom programs, to compiling "stage{1,2,3,4}" for Catalyst, so { cpp, cc1, ld, make, perl, python, lua, ... } have always been the most used processes, and rarely a single process in that list needs more than 200Mbyte of ram, as well as rarely I run more than two big Catalyst-processes in parallel, as well as rarely I need to compile C++ stuff.

Mozilla and Netscape were nice to be built in the early 2000s, once configured, and gcc from v2.96 to 4.1.2 have always been kind in terms of the required ram.

However, when years ago Firefox was written entirely in C++ (now it's an hybrid mess, impossible to be cross-compiled) , I remember there was very high swap pressure with more than 800 Mbytes consumed by gcc.4.5, that means 2.8Gbyte requires on a machine that physically address 2GB.

I remember a couple of "out of ram" crashes because I hadn't allocated any swap, thinking that 2GByte of ram was enough for everything, even because  in 2005, 2Gbyte was a rarity to have on a computer since very expensive.

RAM: 2GB
Swap: 0 <------------ k= 0.0, you assume the ram is already enough

So then my choice was 2GB of disk space instead of 1GB for the swap, as "coverage" safe (k = 1.0), just in case.

RAM: 2GB
Swap: 2GB <------------ k= 1.0

Probably k = 2.0 had/has a similar "coverage" choice behind its shoulders 

[DiTBho]

p.s.
moving from gcc v8.5 to v12 reveals that the new compilers consume 2x times the RAM, and if you don't have enough, that's where if you opted for higher k coverage for your swap.size you made a wise choice.

[Karel]

For me, the reason to add a relatively small swap partition, is just to "get notified by slowlyness" when
the system is about to run out of memory.
I'm thinking about to write myself a little desktop widget that notifies me when used ram reaches
a threshold. In that case I will not use a swap partition anymore.

[DiTBho]

For me, the reason to add a relatively small swap partition, is just to "get notified by slowlyness" when
the system is about to run out of memory.
I'm thinking about to write myself a little desktop widget that notifies me when used ram reaches
a threshold. In that case I will not use a swap partition anymore.

love this idea, just ...
if I implemented that monitor on my router, I am afraid it would light up and blink more than a Christmas tree 

[golden_labels]

For me, the reason to add a relatively small swap partition, is just to "get notified by slowlyness" when
the system is about to run out of memory.
I'm thinking about to write myself a little desktop widget that notifies me when used ram reaches
a threshold. In that case I will not use a swap partition anymore.

In most workloads you will receive that “notification” without swap too. Processes will wait for file-backed pages.

For a more civilized approach see Pressure Stall Information indicators. The feature is relatively fresh, so also often left unnoticed.

[rdl]

I just installed MX on a new-to-me old computer. I don't think it created a swap partition. All I remember doing was adjusting a slider to choose how to allocate the space between system and home. I'm pretty sure it was using the entire drive. My other Debian 10 computer has a swap partition bigger than the amount of RAM. I don't remember who's idea that was.

[BradC]

I've been using SSDs in my laptops since 2005, servers since 2010 and desktops since 2011. I always make the swap partition at least the size of RAM, and in some cases twice the size (xfs_repair can use a *lot* of RAM) and log/cache everything to disk.

In all cases, on all machines under all circumstances the wear on the SSD is such that the machine itself will be long dead before it exceeds the endurance of the flash. I've never seen it be close to an issue. I have seen plenty of people implement pathological workarounds to a purported issue though.

[magic]

the wear on the SSD is such that the machine itself will be long dead before it exceeds the endurance of the flash

Actually, I have done swap on SSD once upon a time and there were indeed no serious problems with it.
Large SSDs have high write endurance, mine still shows "medium wearout indicator" at 100/100.

The machine had 16GB RAM and swap was lightly used. I kept swap mostly for hibernation.

[DiTBho]

Code: [Select]

____________________________
|                           |
| reverse initiator         |
|                           |                             brdige
|     HBA     iSCSI        FC-optic ---------- FC-optic <========> SAS
|__             ____________|
   |           |
   |           |
   |           |
   |   PCI64   |
___|___________|____________
|      |DMA                 |
|   ___|_______             |
|  |          | allocated   |
|  | 31GB ram | to iSCSI    |
|  |__________|             |
|                         uart
|     SBC     PA8900        |
|             1GB  ram   eth0 ------ ssh
|             ramrootfs     |
|   GNU/Linux               |
| reverse initiator         |
|___________________________|

This is what I use for my-cross-compiling Catalyst 

It's an hacked a computer HBA installed into a mobo with 32GB of ram.

It's how to turn a "server" into a "SAS device", so a remote host can see it as "storage device" for temporary storage, which is 90% of what a tool-chain does.

/dev/sda <------ SDD, ReadOnly, kernel and rootfs ( { /var, /tmp, /build /user } are not mounted here)
/dev/sdb <------ HDD, ReadWrite, { /var, /user } are mounted here
/dev/sdc <------ rSAS, ReadWrite, { /tmp, /build } are mounted here

The host believes /dev/sdc is an iSCSI device, whereas at the end of the cable there is a computer which lends its "ram-disk" pretending to be a true block-device.

advantages:
1) it faster than an HDD (200Mbyte/sec read/write, limited by .. well .. the PA PCIX)
2) doesn't use any flash
3) provides more IOP

disadvantages
1) consumes more electricity than an SSD  (250Watt)
2) it's volatile
3) it's *very* expensive if you have to buy parts, I got mine for 200 UKP (as-is, damaged), and I was lucky

[SiliconWizard]

I don't really see a benefit compared to using a "cheap" dedicated SSD even if it doesn't have infinite lifetime (as I suggested), given the cost and power draw, but to each their own!

[nctnico]

For deskop systems I disable swap. There is no use for it with tens of GB of memory. Even a super fast SSD will be considerably slower. On embedded targets with a smaller memory, I setup a swap to prevent the OOM killer to kick in when an application reserves a lot of memory. In most cases the memory isn't even used. Ofcourse swappiness is set to 0

[alm]

For deskop systems I disable swap. There is no use for it with tens of GB of memory. Even a super fast SSD will be considerably slower. On embedded targets with a smaller memory, I setup a swap to prevent the OOM killer to kick in when an application reserves a lot of memory. In most cases the memory isn't even used. Ofcourse swappiness is set to 0

You might want to (re)read the article by Chris Down referenced by golden_label earlier in the thread, because you are falling into the traps like thinking setting swappiness=0 on a solid state system is a good idea, or that adding swap to a system with a lot of memory would somehow harm performance because the SSD is slower than your memory.

[BradC]

For deskop systems I disable swap. There is no use for it with tens of GB of memory. Even a super fast SSD will be considerably slower.

There's always use for swap. Infrequently (or not at all) parts of applications will get pushed out to swap in order to free up more memory for buffers & cache. My desktop has 64G of ram and still has nearly a gig pushed out to swap at the moment.

You often don't *need* swap, although even with 64G xfs_repair will OOM on a 4TB filesystem I have here. I need to provision another 128G of swap to get that to completion.

[shapirus]

There's always use for swap.

No, except for rare scenarios with heavy disk i/o and processes with big unused/rarely used chunks of data in memory. And not until Used+Buf/cache >= Total.

Here's my desktop where having swap wouldn't improve anything and could make the system less responsive if the kernel decided to move something to swap:

Code: [Select]

$ uptime
 11:47:31 up 32 days, 20:21, 30 users,  load average: 0.79, 1.01, 0.99

$ free -h
               total        used        free      shared  buff/cache   available
Mem:            62Gi        27Gi       3.5Gi       395Mi        32Gi        34Gi

Now, the point in the article referenced earlier,

5. On SSDs, swapping out anonymous pages and reclaiming file pages are essentially equivalent in terms of performance and latency.

is only valid for the "dirty pages", aka data in the buffers that has yet to be flushed to the underlying storage device and that will be forced to flush if the pages need to be reclaimed. If it's for the read cache, then the cost of reclaiming those pages is nowhere near the swap operations, which is typical for a desktop system where the disk workload is mostly read-only.

[alm]

5. On SSDs, swapping out anonymous pages and reclaiming file pages are essentially equivalent in terms of performance and latency.

is only valid for the "dirty pages", aka data in the buffers that has yet to be flushed to the underlying storage device and that will be forced to flush if the pages need to be reclaimed. If it's for the read cache, then the cost of reclaiming those pages is nowhere near the swap operations, which is typical for a desktop system where the disk workload is mostly read-only.

Here you assume that the anonymous pages and read cache are equally likely to be needed; but if the kernel decided to swap out the anonymous page, its algorithm predicted that the read cache page is more likely to be needed. Why would you want to take away this choice from the kernel by preventing it from swapping out anonymous pages to save a tiny amount of SSD storage? My desktop has been doing some heavy I/O over night and is still doing it, and with 32 GB RAM is currently sitting with 490 MiB free, 5.6 GB used, 26GB buffer/cache and 2.6 GiB out 8GiB swap usage for a number of hours. Clearly it hasn't needed those 2.6 GiB all morning. So the result without swap would have been 2.6 GiB less buffers / cache for the gain of a few GB SSD storage. Would the 2.6 GiB less buffers have negatively performance? I can't tell, but I'm certainly not missing the 8 GiB of SSD storage.

[shapirus]

Here you assume that the anonymous pages and read cache are equally likely to be needed;

Correct. It depends on the use case actually.

but if the kernel decided to swap out the anonymous page, its algorithm predicted that the read cache page is more likely to be needed.

Yes. This in turn means that the usefulness of swap depends on how accurate the kernel prediction algorithm is for a given use case. In my practice I rarely (if at all) used swap as anything but "emergency memory", but yes, sometimes it can be useful. Heavy disk I/O is a good hint that enabling swap should be considered.

[SiliconWizard]

So, for typical desktop use (not talking about server use), assuming you're actually not running out of memory, whether this actually gets your better performance on average in any given, real-life situation (as is often claimed here and there) is almost undecidable. You can only cherry pick very specific situations for which it actually would, and then claim that whoever disables swap is an idiot.

So you end up choosing enabling/configuring or disabling swap altogether based on a non-entirely rational decision, and some in this thread have evoked that it was even almost a political fight on some level.

[alm]

So, for typical desktop use (not talking about server use), assuming you're actually not running out of memory, whether this actually gets your better performance on average in any given, real-life situation (as is often claimed here and there) is almost undecidable. You can only cherry pick very specific situations for which it actually would

On average it will either improve performance by giving the kernel more options in how to most efficiently manage memory or just not make a difference. Only if you cherry pick very specific situations where the kernel gets it wrong might it negatively affect performance. Whether that's enough to warrant the effort and SSD storage to set up swap is up to the individual.

then claim that whoever disables swap is an idiot

There's a difference between saying "you're wrong for disabling swap" and "you're wrong for disabling swap with the goal of improving performance".