So there is a lot of “received wisdom” or “folk advice” but really it’s mostly just cargo-cultism about how to configure swap space on Linux servers. And for my experiences, that advice hasn’t worked out well for me.
Now, just to be specific (in order to be Terrific as my lovely wife loves to say), I am talking about servers and I’m talking about Linux – on Desktop, and/or on other operating systems, these things might be very different. Anyways, that’s the set-up, let’s talk about what I think.
So I’ve read a lot of things. Some saying 2x RAM is good for swap, some saying 1/2xRAM is good. But my argument is, that on a server system, the correct amount of swap is zero. No swap. None. Zilch. Nada.
So you can see elements of this argument when you look at an overloaded server who has waaaaaaay too much swap assigned. You will run into an issue called “thrashing” – where one process wants to run, and it has to swap in a bunch of stuff from disk, then it runs for a few milliseconds, and then control moves over to another process, who also needs to swap stuff off disk, knocking the previous processes’ loaded-up chunk of RAM. Anybody who’s ever ssh’ed in to a server that is absolutely CCCCCRRRRAAAAWWWLLLLLIIIINNNNGGGGG will have seen this type of behavior before. Everything goes very, very bad. Including the entire system just “locking up” entirely, so you have to restart it. Not awesome when that happens. So that’s what happens if you have way too much swap allocated. So, obviously “too much” swap is certainly “bad.” Otherwise, why wouldn’t we say make it as much as you need? Or make it as much as the disk already has empty? That’d be easy enough to write. But we don’t, because, my friends, “thrashing” is very real.
So that certainly begs the question, “OK, definitely don’t want ‘too much’ swap, what is the right amount of swap?” Well, that’s an open question, of course, but one for which I have an answer. But to give that answer, I need to explain the logic of people who do want to enable swap on a server.
The thinking is, as I understand it, that you want to make sure that if there is some amount of memory allocated by various processes that are running, but somehow, not currently actively being used, then we want to enable swap so that RAM can be flushed out to disk, and make more memory available to processes that are going to be actively using the memory they’ve allocated. And that’s a noble goal! One worthy of seeking – why waste memory on something that no one has asked for or asked about, when you have other processes that need it?
But that’s not the whole story.
So, IMHO, Linux has the best Memory Management and Virtual Memory Management in the entire world. Nothing else comes close (well, as of 2026, maybe plenty of others do. But Linux was the first and has always been the best IMHO). An early decision to unify the filesystem buffer cache and the VM subsystem into one big giant thing I think has made Linux an extremely high-performer in terms of down-in-the-dirt, basic, normal filesystem and RAM types of tasks. Let me explain how it works.
So, as I understand it (and of course Linux kernel folks who know more than me, by all means feel free to contradict me), Linux will basically use every single available byte of memory that you have for filesystem cache. Files that are accessed most often? Hot in the cache. Files that have been evicted because they’re not accessed very much? Not there. When your app says “Gimme a gig o’ RAM” and then fills it with the fibonacci sequence – the Linux memory manager just “forgets” about pages that it knows are already on disk, and was just caching for performance. So we’re already getting the advantages of VM, without swap enabled!
That process that you’re running, where one big chunk of code at the beginning is never run again? That chunk got evicted from the cache a long time ago, already, without you doing anything – because it’s been mapped directly from the binary file; the system can get that piece back if something needs it from that file that’s already on the filesystem. That process that said, “wait, I might need a HUGE chunk of RAM!” and allocated 1G, but is not using it yet? Yeah, that’s not taking up any space in RAM either. You can even see this if you look at top. There are two numbers to pay attention to: RES and VIRT. RES is how much memory from this process is actually RESident in memory; that’s the number you have to plan for. But the VIRT – that’s how much virtual memory you have associated with this process. If it’s sufficiently misbehaved, it could suddenly go and eat all of that real, live RAM up, in a heartbeat, and that would probably cause some real stress on your system. But real life doesn’t work that way – servers tend to run the same tight loop, just a lot of times in a row (or in parallel). So whatever is warm in cache (RAM) is probably the stuff that you want to be taking up your RAM. For the system I’m looking at right now, the VIRT for this one MySQL process is ten times the size of what’s resident.
So, what do you actually lose when you disable swap on your Linux server? Well, as I mentioned, the actual binaries you’re running – all the same. The data files you have open – definitely the same. The one thing you do lose, is if you have an application that allocates a big giant chunk o’ RAM, and then fills that RAM with all kinds of interesting data – under what I’m proposing, that will never get evicted from RAM. Ever. And if that’s a problem for your specific use case? Then by all means, do not use what I’m saying here. But I do think that’s really, really, really, really niche. If something wants to allocate something that’s huge and rarely accessed and doesn’t need to be “warm,” it’s just going to create a file, and mmap() it into memory. That just makes more sense.
So I can see some objections to my theory, and I’ll try and state them and refute them for you right now.
- But what if my system is completely running out of RAM, and I need to spawn this one specific process? – Well, then, my answer is the “Vaudevillian Doctor response” – which is “Well, don’t do that then.”1 Tune your system so that that doesn’t happen. I think it’s better for the process to just simply fail rather than push you into a thrashing trap, which will absolutely down your server. Better to fail hard now rather than turn the server into a giant heap of molasses that you have to somehow manually force to reboot.
- What about processes that allocate big giant heaps of memory and then fill that memory with a bunch of stuff, but then don’t use it? – I mean, generally, they shouldn’t. But if they did, it was probably for a reason. And they probably need access to whatever that is, and fast. Paging it out to disk is going to make that expectation fail. And that’s, typically, not the stuff that we’re flexible about whether or not it’s on disk. We’re caching big giant MySQL databases (also memory-mapped), and hoping (or trying to ensure) that the appropriate indexes are all in-RAM. So I don’t think this loss is a bad thing, I actually think it’s a good thing. The system just asked for a giant chunk of RAM and filled it with stuff. If it wanted a file, it would’ve made one. It asked for RAM. Give it what it asks for.
- What about processes that are actually running and taking up RAM, real RAM, but not actually doing anything? Uhm, don’t run those please? And if you have something that could do something, but isn’t currently doing something, most of the body of the binary is going to get evicted from cache until it’s actually needed.
So one thing that could happen in this scenario is if you have enough processes, all running at the same time, and memory is constrained, and the OOM-killer is firing, and everything is going bad, and processes start to slow down because Process A has to swap in its binary to execute some code there, but then process B fires and it has to swap out the stuff from Process A? Uhm, get more RAM. That’s pretty much it.
I’ve been usually running Linux servers without any swap enabled for around 10 years or maybe a little longer, and have had better results from it. I’d far rather have a server “hard fail” rather than fall into thrashing hell. “Hard fail” I can probably ssh into and reboot or stop processes or something. A thrashing server, you usually can’t even ssh into. (Today, in AWS, I had to actually open up the serial console to talk to one of my boxes. “Nada bom” as we say here in Portugal – “Not Good at all.”)
I’m happy to hear about opposing viewpoints. While this has been my experience, it doesn’t mean that it’s yours – so I’m happy to hear evidence to the contrary.
Happy servering everyone!
- This is from the very, very old Vaudeville joke “Doctor, doctor, it hurts when I do this!” And the doctor response, “Well, don’t do that then.” ↩︎