Is there ever a good reason to disable swap?
https://serverfault.com/a/684800/2321 indicates it is "not recommended" (at least on Linux), and I have always setup at least some swap on every machine I have had since moving off DOS in the early 90s
Is there ever a good reason to not enable it (on any OS)?
86 comments
[ 4.6 ms ] story [ 170 ms ] threadAlso on a dedicated systems where you have full control of the stack, the apps, and have resource limits in place anyway. If you know your embedded system will never need more than X GB, you can use it as resource limit of last resort. (And hopefully let the watchdog reboot it after the required app fails to check in)
Lots of the arguments for swap/paging seem to ignore the possibility of just buying "overkill" amounts of RAM.
On the other hand, if you have truly enormous data sets you can RAID 4 M.2 SSDs to max out a PCIE 6.0 x16 slot for 121GiB/s bandwidth in a multiple-TiB swap file. It'll be a while until SSDs get big enough for this to max out the 256TiB virtual address space of x86_64, but you can get 8TiB M.2 SSDs now...
It's a very rare corner case.
In that situation, swap provides exactly the wrong thing - it attempts to keep up with memory demand by doing a more expensive and slower version of regular processing. That’s a key ingredient in the recipe for congestion collapse.
No. 99.9% of servers are running more processes than the main workload. There are all sorts of security, monitoring, auditing, inventory tools that might run occasionally.
As I wrote, it's a rare corner case.
Hello time traveler, what year do you live in to have regular servers with “dozens of thousands” of GB…
Though if you have $400/hour to spend, you can get an u7in-32tb.224xlarge in AWS us-east-1 region.
No, it gives you progressive performance degradation instead of a hard failure and this is a feature and not a bug.
I can't remember when I dabbled with a swap partition for the last time.
Now that I saw this post, I ran "swapon -s" on my laptop and on my servers. It comes back empty everywhere.
Why would I ever create a swap partition or file in the first place? Isn't it something from the past when RAM was scarce?
For server workloads, you probably never want to use the swap, but it’s safest to have it enabled because you don’t know which process is going to get killed when memory runs out. You can monitor for swap usage and tweak your settings appropriately.
But for some things, especially with some k8s uses, overprovisioning can be okay. Some stuff just needs to run somewhere where cost of swiping in or out is lower than cost by provisioning more/bigger machines or cost of scaling from zero to one and back.
For a good article on why this is true for Linux: https://chrisdown.name/2018/01/02/in-defence-of-swap.html
I believe that most operating systems are going to make use of memory in a similar manner.
With that said, I'll turn off swap on devices that have unreliable storage. (Anything using an SD card)
> Under no/low memory contention
> With swap: We can choose to swap out rarely-used anonymous memory that may only be used during a small part of the process lifecycle, allowing us to use this memory to improve cache hit rate, or do other optimisations. > Without swap: We cannot swap out rarely-used anonymous memory, as it's locked in memory. While this may not immediately present as a problem, on some workloads this may represent a non-trivial drop in performance due to stale, anonymous pages taking space away from more important use.
This is under the low/no memory contention. For the low memory contention case, this can make sense, but for the no contention case it's nonsense. There's no more important use, all uses are fulfilled and there's still free memory (that's what "no contention" means)!
So clearly that very page has presented a case where swap is useless: when you have enough RAM to ensure there's never contention.
Swap also only extends the amount of memory by the size of the swap partition. If you've got 64GiB of memory and an 8GiB swap partition, you could just as well have 96 or 128GiB of memory and reserve an 8GiB zram for swap.
Indeed, Fedora changed to use zram instead of swap-on-disk by default in Fedora 33[1].
Swap does allow some fancier optimizations to memory layout, but again swap-on-zram is better for this than on a disk if you've got enough RAM.
The big benefit of swap is on laptops where hibernation may actually be desirable (assuming encrypted swap & disk) and RAM is harder to come by. A laptop with 96GiB+ of RAM is a LOT more of an expense than a desktop with the same.
One huge disadvantage of swap-on-disk that article neglects to mention is that sensitive data from RAM can be written to persistent storage (swap) and henceforth leaked more easily (assuming unencrypted swap). Swap must be encrypted if it's disk-backed.
[1] https://fedoraproject.org/wiki/Changes/SwapOnZRAM
It's also based on observations of performance - for many moons, the performance hit of swapping was bad enough that it was never worth it to run two jobs concurrently that didn't both fit into ram together. The exceptions weren't even exceptions. Disk thrashing was a serious impediment and way to slow your whole fleet down.
Now with fast flash being so common, swap is probably actually a good thing for many workloads again, but only "many", and SREs would prefer you make that explicit by using memory mapped files for data that's of random utility, so that the OS can manage that pressure for you, understanding that those files don't need to be fully resident.
[1] This is an oversimplification that I don't remember the real truth of off the top of my head
DDR5 Latency = 16.67ns
DDR5 Bandwidth = 64GB/s
Now, keep in mind, this doesn't account for things like dual or quad channel which bumps up the bandwidth even further though doesn't really affect latency.
The fastest and most reasonably priced consumer NVMe I could find:
NVMe Latency = 200000ns
NVMe Bandwidth = ~3GB/s
The fastest consumer (or low enterprise) grade persistent storage is terribly slower and takes longer to respond than the cheapest DDR5 ram.
Still waaaaaaaaaaaay slower than ram, but getting closer. Before giving up on optane, intel used to make memory modules with optane on them (as a form of backup I think)
[1]: https://www.intel.com/content/www/us/en/products/docs/memory...
From the mentioned article:
“Bandwidth problems can be cured with money. Latency problems are harder because the speed of light is fixed; you can’t bribe God". David Clark
I think my only device with swap is my Mac laptop and it is relatively conservative when it swaps, unlike Linux with default settings.
If your question was "why not keep swap on and change the default swap-iness settings", if keeping it totally off works fine for them, why bother?
Yes. It's a rare system that it shouldn't be enabled.
RAM is a precious resource. It's highly likely programs will allocate RAM that won't be used for days at a time. For example, if you are using docker once the containers are started the management daemon does nothing. If you have ssh enabled only for maintenance it unlikely to be used for days if not weeks on end. If your system starts gettys they are unlikely to be used, ever. The bulk of the init system probably isn't used once the system is started.
All those things belong in swap. The RAM they occupied can be used as disk cache. Extra disk cache will speed up things you are doing now. Notice this means most of the posts here are wrong - just having swap actually gives you a speed boost.
One argument here is that disabling swap provides you an early warning system you need more RAM. That's true, but there is a saner option. Swap is only a problem if the memory stored there is being used frequently. How do you monitor that? You look at reads from swap. If the steady state of the system is showing no reads from swap, you aren't using what's there, so it can't possibly have a negative speed impact. But if swap is being used and isn't being read from, it's freed some RAM so it is having a positive speed impact.
One final observation: the metric "swap should be twice the size of RAM" isn't so helpful nowadays. There aren't a lot of programs that sit around doing nothing. Maybe 1GB or so, and it's more or less fixed regardless of what the system is doing. Old systems didn't have 2GB of RAM, so the "twice RAM" rule made sense. But now a laptop might have 16GB. If you are using 32GB of swap and not reading from it would be a very, very unusual setup. If you are reading from that 32GB or swap, you're system is RAM starved and will be dog slow. You need to add RAM until those reads drop to 0.
Remembered when I thought "if double is recommended, four times should be even better!". It was not.
Nowadays I don't use swap because I rarely run out of RAM, it sits there eating a few precious GB of SSD, largely unused. The rare cases when I run out of RAM have been buggy Steam games on Proton. In 2024, it has been only "The Invincible", and that game has reports of running out of memory on Windows too.
Right now if I look at my Firefox processes, they take more (10-20%, sometimes a lot more) more commit size (virtual memory) than their private working set. With page files the unused virtual memory portion is simply reserved on the page file with minimal overhead. Without any page files, you will be just wasting memory.
RE: unnecessary writes, it might be windows proactively dumping the contents of the memory (I think this happens but I cannot confirm right now). But in general that's very low priority and it should affect your performance.
Check out RAMMap from the absolutely excellent system internals to see how your system memory is allocated currently, even per-process.
As an example, I have 64G of ram, showing ~40GB "used" as per task manager. Of that however only 22GB is private process active. The rest is memory-mapped files, standby, paged pool, nonpaged pool, shared etc.
The issue with pagefile - say there is also a 64GB pagefile - is that windows is notifying processes and the memory manager is considering that the system has "128GB" of ram, which many processes will take as a sign they can reserve more memory and causing an inflation of reserved actual ram.
It is less of an issue now that the memory manager is tier aware and applications have ABIs to check and request memory in a more informed way.
Writes on an SSD are always an issue unless you're running SLC or similar high endurance flash.
Swap on means applications may be slower due to page faults requiring swapped out memory. Swap off may mean file system operations are slower due to less opportunity to file system cache frequently used objects.
There is still a trade off here on performance balanced against use case.
If you have no swap, anonymous pages (stacks, heaps) cannot be evicted to disk and the thrashing is forced onto the disk cache. So the hard lock-up occurs earlier.
If you want to delay the lock-up as much as possible, enable swap and set swappiness high.
My experience is really the opposite from this. Thrashing was a normal occurrence on my desktop, where it went into non-recovery and a manual hard reset.
And also, with 16GB ram and 4GB swap, my running applications got moved to swap. Switching tabs in Firefox will be slow because it has to come from swap. My swappiness was set to 1 that it shouldn't swap, but it did swap always.
Now without swap and using early_oom everything is fine. When I see in /proc/vmstat that there has been a kill, it is time to reboot.
On my laptop though, my usecase is different. It only has 2GB ram, so I prefer swap over a hard kill. And I reboot it more than once a day if I am using it.
If you want a hard OOM kill, i don't know. I'm only talking about the I/O lockup that happens in these situations.
The TLDR is GC pauses were high enough to be causing problems in a particular service, at the time the swap was on rotating media so latencies on a page fault were high, and this was especially a problem during mark and sweep operations leading to long pauses. Due to other GC tuning and the overall IO workload, disabling the swap made sense for the particular servers.
But if I had to do it today the situation might be very different, I might have NVME drives to drop swap onto with much better access latencies, or be able to use mlock to lock critical pages and preventing swapping, etc.
Also, there are some very clear problems introduced with disabling swap, especially on NUMA systems. Again, the particular times I disabled swap, we were able to lock processes onto their relevant numa nodes and do other tuning to make this worthwhile.
So as a general rule, especially with modern hardware, I would agree that it isn't recommended. However, you can probably find narrow use cases where amongst a number of other tunings it makes sense to drop swap. Also, there are plenty of other things you likely want to tune before removing swap.
Every instances were designed to:
So we had some known requirements (the "app" line) and some variables requirements (IO cache and "basic server requirements")Some extra informations:
No oom and no waste