512MiB no mater how much RAM you have. Keep in kind this is based on "it seems to do the trick" rather than any proper reasoning. But hey, so is the article, I guess.

My reasoning is as follows (ams concludes that swap does nothing): 4GB RAM, no swap. Firefox allocates all RAM. Linux starts taking the program code and data sections out of disk. Serious thrashing. Hang.

4GB, some swap. Firefox allocates all RAM. Some stuff is in swap. Firefox allocates more memory. Swap is full of firefox's stuff. RAM is full of firefox's stuff. Linux starts taking the program code and data sections out of disk. Serious thrashing. Hang.

It's the same thing, just more complicated thus harder to debug. It will behave better, if you never get to fill RAM+swap. But today's programs simply allocate more. And the kernel says yes.

IMO the real solution, given that we overcommit, is for firefox to check that % RAM usage you see in top(1) and to try to not let it go above 95% by freeing cache, and for the kernel to do OOM killing early.

> IMO the real solution, given that we overcommit, is for firefox to check that % RAM usage

Doesn't it to that already? I remember 3-4 years ago I use to watch in amazement how people complained that Firefox ate over 2GBs of memory, whereas I ran it on a laptop with 2GB total, and FF rarely hit 1G even with dozens of tabs open.

EDIT: Mozillazine seems to confirm my experience: "These numbers will vary because Firefox is configured by default to use more memory on systems that have more memory available and less on systems with less" (http://kb.mozillazine.org/Reducing_memory_usage_-_Firefox)

This is annoying on Android. System normally would kill (or suspend or whatever Android exactly does in those circumstances) other applications if Firefox ate too much of memory. And I would be happy with that, but unfortunately under memory pressure Firefox kills less important tabs. With memory hog in the backgrounds (these wonderful mobile games) I can jump between maybe 2 or 3 tabs before Firefox starts killing.

There are small systems in which 512 MB (or MiB) isn't available, but in which some swap might conceivably be useful. Mostly networking gear, which still ships with absurdly low storage/memory allocations (my DLS router is 64 MB RAM, 8 MB flash, as an example).

Not unviable under the stock OEM firmware, but confining when switching to, say, OpenWRT. Not that I'd know about this or anything.

THe default for debian 9 was 100% of ram. I have 64 gigs, so it was a bit much (especially as I only have 128 of disk.)

The only time I've ever seen my[1] swap go above 500 megs was when I was running qterminal with a memory leak. It was a long running terminal, with a long running process that was extra ordinarily chatty.

4 gigs is probably enough for most people under most conditions.

[1] this is workstations. on servers, I've seen it happen all the time. Crucially it gives one time to react.

I just did a fresh install of Debian 10 and it is still the default. I understand that they want to support hibernation out of the box but it creates gigantic swaps for a feature that I believe is rarely used, nowadays sleep is good enough and reboots are super fast.

It would be great if the installer optionally asked how much swap to allocate without having to do the full partitioning manually.

Interestingly enough the debian installer freaks the fuck out if you have more ram than disk and choose the auto-partition option. We've run into this a few times with servers that have 512gb ram and a 120gb ssd installed. The installer doesn't seem to recognize this and try to set some sort of sane swap amount, instead it gives you some cryptic error messages about a bad disk and hangs.

You mention time to react. How do you get notified that memory usage is getting out of hand before the system is actually unusable?

Depends on the service its running really.

I'd assume that you'd have key metrics plotted in grafana, so its case of following up/alerting on that

In previous cases, It was fairly simple, an alert was fired because the queue size ballooned. Looking at the machine stats we saw that all the ram cache had been ejected just at the same time performance started to drop.

Either way, its pretty trivial to put an alert on a stat in grafana.

however, your mileage may vary.

It depends on your workload, does it not? Generally you'll want swap to be mostly unused, so you don't need a lot, but if you want to eg. hibernate a laptop, you'll need at least as much as you have RAM to do it.

Also If you use tmpfs you should have enough swap to cover the size of your tmpfs partitions in their entirety so that a bad application won't eat all your memory.

It depends on what you're doing on the box. Lots of disk I/O and lots of different apps each causing a spike of RAM usage at a different time, like a typical LAMP server? You probably need a bit more swap. Just one app with a very consistent RAM usage, like a database server with an explicitly configured buffer size? Then you don't need much swap. The old rule "2x RAM" actually isn't bad on a desktop PC, but it's a terrible default on a server.

Linode has been configuring 256MB swap partitions by default on their VPS for a long time, even for large plans. Maybe it's bigger for the really large plans, but I haven't tested them. Anyway it feels like a nice default, and seemed to work fine with most kinds of loads in 10+ years of usage. Some of the newer VPS services (DigitalOcean, Lightsail) come with no swap by default, and I don't feel comfortable about it so I add a 256MB swapfile on them. I do turn down the swappiness a bit, though.

Just as a gut-feeling guess, I feel like 256MB or 512MB should be fine. I don't think we need to deal with percentages; the number is likely independent of the total RAM amount. Not enough to run things on (and you don't want to run things on swap anyway), but enough to get you out of the weeds when the system is under heavy memory pressure.

If you don’t hibernate or other reasons to use swap, what does adding half a gig of swap do that adding that as extra ram doesn’t?

Or more practically, if I’m doing stuff with 8gigs and then I upgrade to 16gigs of ram, then why would I need to keep my 512mb of swap? Surely the extra 8gigs comfortably covers that extra room? Am I missing something?

> If you don’t hibernate or other reasons to use swap, what does adding half a gig of swap do that adding that as extra ram doesn’t?

Linux (and generally most popular OS) really don't like having no swap whatsoever (https://lkml.org/lkml/2019/8/4/15).

Plus if you're running out of RAM (regardless of how much you have, sure put more in if you have it) the system starts visibly degrading but remains recoverable when it starts swapping. If it can't swap, it pretty much just dies.

> If it can't swap, it pretty much just dies.

The point with my example was that if 512 MB of swap would save you, then why wouldn't 8 GB of extra RAM save you?

Yes, if you run out of RAM, you're in trouble, but if you run out of RAM+swap you're in trouble too, so what's the point in adding a small 256 or 512 MB swap?

Ok, so the point is that its visibly bad with swap before it actually dies, giving you time to recover. How about setting up some kind of alert when you're in your last half a gig or gig of RAM then? It seems like this would give a much better recovery experience. If its a server, you need an alert anyway since you're not going to notice the bad performance until its too late, most likely (you're not watching it 24/7 I assume).

Of course, from the article:

> I stand by my original position: have some swap. Not a lot. Just a little. Linux boxes just plain act weirdly without it.

That's fair enough, if the reason is to stop linux from acting weirdly, then fine.

> The point with my example was that if 512 MB of swap would save you, then why wouldn't 8 GB of extra RAM save you?

Having 8 GB more RAM might avoid the issue, but it won't visibly degrade the system so you will not see that you're in trouble.

And again if you can have both, have both.

> Yes, if you run out of RAM, you're in trouble, but if you run out of RAM+swap you're in trouble too, so what's the point in adding a small 256 or 512 MB swap?

Because if you run out of RAM and have no swap, the system dies. If you run out of RAM and have swap, it starts swapping, which is noticeable.

> How about setting up some kind of alert when you're in your last half a gig or gig of RAM then? It seems like this would give a much better recovery experience. If its a server, you need an alert anyway since you're not going to notice the bad performance until its too late, most likely (you're not watching it 24/7 I assume).

If it's a server you need to do that anyway because the swapping will probably not be noticeable.

> Because if you run out of RAM and have no swap, the system dies. If you run out of RAM and have swap, it starts swapping, which is noticeable.

Only if you're using the system, or are reacting to monitoring (if you can monitor it and the thing you're monitoring fails) fast enough

I'd rather have a dead system than one that's not working

But in any case shouldn't OOM killer come to the rescue?

> But in any case shouldn't OOM killer come to the rescue?

Indeed. Its similar to the argument that segfaults are good due to fail fast. Wouldn't it be better to fail fast due to OOM than to hobble along?

If you're actively using the system, ok, you might get a chance to save your work or whatever first, but, in my personal anecdotal experience, that process is pretty much dead anyway and I have to kill it. Yes, my system doesn't get taken down, but if OOM takes the system down, why isn't the kernel killing the process that's eating all the memory? It sounds to me that swap is just masking the problem.

> I'd rather have a dead system than one that's not working

A swapping system is degraded, not "not working".

> But in any case shouldn't OOM killer come to the rescue?

The OOM killer will heuristically kill random crap. It could be the process with an unbounded memory growth, or it could be your text editor.

I think the point is that you want to know when you are approaching the limit so that you can start shutting down things instead of having your system crash on you.

Have an alert trigger when your RAM gets low? On desktop systems, I've literally never had any problems where I wasn't already aware that my RAM was low (and therefore made sure I saved my work etc) and on servers, I'm not watching them 24/7, so need alerting anyway. A tiny amount of swap only buys you a tiny amount of time.

For mixed workload servers I tend to go for 1GB swap, vm.swappiness=0 and then alerts on around 300-400MB of swap usage. I found alerting on swap to be the best indicator of impending doom, whether it's from a slow memory leak or a buildup from an i/o bottleneck.

Usually a sqr of your total ram. Zram is a another option as it a block device that does virtual ram.

Square root of what unit? That's going to give different results if you measure in gigabytes, bytes or bits.

Almost certainly gigabytes.

Try some numbers yourself.

Anything kilobyte or below gives you effectively zero swap.

Megabytes gives you 90MB of swap on a machine with 8GB ram, that's an unusually small number and if it was supposed to be that small the advice would probably just be "128MB for all".

Gigabytes fit the idea that if you have a smaller amount of ram, you have swap comparable to it, but once you scale up you don't add a lot more for each gig.

Terabytes gives you hilariously large numbers for computers with 64GB of ram or less.