> I stand by my original position: have some swap. Not a lot. Just a little.
Is there some exact figure on this ? Like how much percentage of RAM size should be allocated as swap space.
Is there some exact figure on this ? Like how much percentage of RAM size should be allocated as swap space.
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.
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)
Not unviable under the stock OEM firmware, but confining when switching to, say, OpenWRT. Not that I'd know about this or anything.
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'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 would be great if the installer optionally asked how much swap to allocate without having to do the full partitioning manually.
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.
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.
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?
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.
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.
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.
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?
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.
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.
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.