Early BSD VM pre-allocated swap backing for every anonymous page — you couldn't allocate virtual memory without a swap slot reserved for it, even if the page was never paged out.
When a process forks, the child needed swap reservations for the parent's entire address space (before exec replaces it). A large process forking temporarily needs double its swap allocation. If your working set is roughly equal to physical RAM, fork alone gets you to 2x.
This was the practical bottleneck people actually hit. Your system had enough RAM, swap wasn't full, but fork() failed because there wasn't enough contiguous swap to reserve. 2x was the number that made fork() stop failing on a reasonably loaded system.
The later overcommit/copy-on-write changes made this less relevant, but the rule of thumb outlived the technical reason. Most people repeating "2x RAM" today are running systems where anonymous pages aren't swap-backed until actually paged out.
Today swap is no longer about extending your address space, it's about giving the kernel room to page out cold anonymous pages so that RAM can be used for disk cache.
A little swap makes the system faster even when you're nowhere near running out of memory, because the kernel can evict pages it hasn't touched in hours and use that RAM for hot file data instead.
The exception is hibernation — you need swap >= RAM for that, which is why Ubuntu's recommendations are higher than RedHat's 20% of RAM.
Today's swap also is not preallocated by the user. It is entirely handled by the OS itself. If it needs swap space to hibernate it will go ahead and allocate it itself.
TBF, I think overcommit was and remains an ugliness in how we manage memory. I wish we'd solved the fork commit-charge-spike issue by encouraging vfork (and later, posix_spawn) more heavily, not by making the OS lie about the availability of memory.
The ship's long sailed though, so even I run with overcommit enabled and only grumble about what might have been.
The OP clearly states that he wants to know the earliest origin of the rule, and the only answers he gets are people giving their own opinions on how much swap space you should have.
Too bad because it's an interesting question that I would also like to know the answer to.
Nope. Those are not the only answers I am seeing. I’m still curious though. 2x was nice because nobody really questioned it. Now that we have there doesn’t seem to be one “answer”. This is a fun/interesting question that comes up every now and then here and elsewhere :-)
I suspect someone smarter than me about system tuning will have a much smarter and nuanced answer than “just use 2x”
I thought the modern advice was you don't need it at all. No more spinning disks, so the there's no speed gain using the inner-most ring, and modern OSes manage memory in more advanced, and dynamic ways. That's what I choose to believe anyway, I don't need anymore hard choices when setting up Linux :)
The main downside to not having swap is that Linux may start discarding clean file backed pages under memory pressure, when if you had swap available it could go after anonymous pages that are actually cold.
On a related note, your program code is very likely (mostly) clean file backed pages.
Of course, in the modern era of SSDs this isn't as big of a problem, but in the late days of running serious systems with OS/programs on spinning rust I regularly saw full blown collapse this way, like processes getting stuck for tens of seconds as every process on the system was contending on a single disk pagefaulting as they execute code.
Managed over 50k servers with zero swap. Simply set overcommit ratio to 0, min_free configured based on a Redhat formula and had application teams keep some memory free. Servers ranged from 144GB ram to 3TB ram. On servers meant to be stateless app and web servers panic was set to 2 to reboot on oom which mostly occurred in the performance team that were constantly load testing hardware and apps and a few dev machines were developers were not sharing nicely. Engineered correctly OOM will be very rare and this only gets better with time as applications have more controls over memory allocation. Java will always leak, just leave more room for it.
I've had arguments with people about this for 20 years now and the most compelling case I heard involved the price of storage vs the price of RAM in the mid to late 1990s, and that this 2x represented an optimal use of money in designing a system at that point in time.
I install more RAM so I can swap less. If I have 8 GB, then the 2x rule means I should have a 16 GB swap file, giving me 24 GB of total memory to work with. If I then stumble upon a good deal on RAM and upgrade to 32 GB, then if I never had memory problems with 24 GB, then I should be able to completely disable paging and not have a problem. But instead, the advice would be to increase my paging file to 64 GB!?
It's not meant for that kind of comparison. It's a variant of Simpson's paradox. Any individual system with a fixed set of tasks needs less swap when it gets more RAM. But when you look at the aggregate of systems, the systems that have more tasks to run get more RAM to run them, and systems with fewer tasks get less RAM. And since more tasks need more swap, everything scales together (though often not linearly).
in 1997 people talking about it on the Slackware Usenet group:
>Question: Why do you need 500MB of swap space? You would be better of
>spending your money on more RAM than wasting it on so much swap space,
>considering that it would most likely never be used anyways.
I work with systems that have between 256MB and 1GB of RAM and
between 4GB and 16GB available for Linux. My experience with other
operating systems is that swap should be 2X to 3X RAM
...
I know there are broken OSes out there where it's recomended to
have 2x RAM swapspace, but Linux is not broken in that way.
With Linux you should have <Max needed memory> - <RAM> swapspace,
and depending on your needs that might range from 0 to infinity
MBs of swap.
...
THIS IS CRAZY!!!! YOU DON'T KNOW WHAT THE F--K YOU'RE TALKING ABOUT.
Windows: I set min size to whatever is necessary to make RAM+swap add up to ~2 GBytes per CPU thread, to avoid problems with parallel Visual Studio builds. (See, e.g., https://devblogs.microsoft.com/cppblog/precompiled-header-pc...) Performance is typically fine with ~0.75+ GBytes RAM per job, but if the swapfile isn't preconfigured then Windows can seemingly end up sometimes refusing to grow it fast enough. Safest to configure it first
macOS: never found a reason not to just let it do whatever it does. There's a hard limit of ~100 GBytes swap anyway, for some reason, so, either you'll never run out, or macOS is not for you
Linux: I've always gone for 1x physical RAM, though with modern RAM sizes I don't really know why any more
Zero. My office workstation has 48 GB of RAM, my home computer has 64 (I went a bit overboard). I have very bad memories of swap thrashing and the computer becoming totally unresponsive until I forced a reset; if I manage to fill up so much RAM, I very much prefer the offending process to die instead of killing the whole computer.
I did similar with my 32GB laptop, but it was fairly flaky for ~4 years and I just recently put 48GB of swap on and it's been so much better. It's using over 20GB of the swap. The are cases in Linux where running without swap results in situations very similar to swapping too much.
It's funny how people think they're disabling swapping just because they don't have a swap file. Where do you think mmap()-ed file pages go? Your machine can still reclaim resident file-backed pages (either by discarding them if they're clear or writing them to their backing file if dirty) and reload them later. That's.... swap.
Instead of achieving responsiveness by disabling swap entirely (which is silly, because everyone has some very cold pages that don't deserve to be stuck in memory), people should mlockall essential processes, adjust the kernel's VM swap propensity, and so on.
Also, I wish we'd just do away with the separation between the anonymous-memory and file-backed memory subsystems entirely. The only special about MAP_ANONYMOUS should be that its backing file is the swap file.
mmap is not swap. It's using the same virtual memory mechanisms to load/dump pages to disk. The policy for when to read and write those pages is completely different.
On systems with 32/64/128 GB of ram, I'll typically have a 1GB or 2GB swap. Just so that the system can page out here and there to run optimally. Depending on the system, swap is typically either empty or just has a couple hundred MB kicking around.
On what OS are you using these settings? I found that Windows will refuse to allocate more virtual memory when the commit charge hit the max RAM size even if there is plenty of physical memory left to use.
I have 64 GiB of RAM and programs would start to crash at only 25 GiB of physical memory usage in some workloads because of high commit charge. I had to re-enable a 64 GiB SWAP file again just to be able to actually use my RAM.
My understanding is that Linux will not crash on the allocation and instead crash when too much virtual memory becomes active instead. Not sure how Mac handles it.
My work laptop currently has 96GB of RAM. 32 of it is allocated to the graphics portion of the APU. I have 128GB (2x) of SWAP allocated, since I sometimes do big FPGA Synthesizations, which take up 50GB of RAM on its own. Add another two IDEs and a browser, and my 64GB or remaining RAM is full.
Early BSD VM pre-allocated swap backing for every anonymous page — you couldn't allocate virtual memory without a swap slot reserved for it, even if the page was never paged out.
When a process forks, the child needed swap reservations for the parent's entire address space (before exec replaces it). A large process forking temporarily needs double its swap allocation. If your working set is roughly equal to physical RAM, fork alone gets you to 2x.
This was the practical bottleneck people actually hit. Your system had enough RAM, swap wasn't full, but fork() failed because there wasn't enough contiguous swap to reserve. 2x was the number that made fork() stop failing on a reasonably loaded system.
The later overcommit/copy-on-write changes made this less relevant, but the rule of thumb outlived the technical reason. Most people repeating "2x RAM" today are running systems where anonymous pages aren't swap-backed until actually paged out.
Today swap is no longer about extending your address space, it's about giving the kernel room to page out cold anonymous pages so that RAM can be used for disk cache.
A little swap makes the system faster even when you're nowhere near running out of memory, because the kernel can evict pages it hasn't touched in hours and use that RAM for hot file data instead.
The exception is hibernation — you need swap >= RAM for that, which is why Ubuntu's recommendations are higher than RedHat's 20% of RAM.
Today's swap also is not preallocated by the user. It is entirely handled by the OS itself. If it needs swap space to hibernate it will go ahead and allocate it itself.
TBF, I think overcommit was and remains an ugliness in how we manage memory. I wish we'd solved the fork commit-charge-spike issue by encouraging vfork (and later, posix_spawn) more heavily, not by making the OS lie about the availability of memory.
The ship's long sailed though, so even I run with overcommit enabled and only grumble about what might have been.
The OP clearly states that he wants to know the earliest origin of the rule, and the only answers he gets are people giving their own opinions on how much swap space you should have.
Too bad because it's an interesting question that I would also like to know the answer to.
Nope. Those are not the only answers I am seeing. I’m still curious though. 2x was nice because nobody really questioned it. Now that we have there doesn’t seem to be one “answer”. This is a fun/interesting question that comes up every now and then here and elsewhere :-) I suspect someone smarter than me about system tuning will have a much smarter and nuanced answer than “just use 2x”
I thought the modern advice was you don't need it at all. No more spinning disks, so the there's no speed gain using the inner-most ring, and modern OSes manage memory in more advanced, and dynamic ways. That's what I choose to believe anyway, I don't need anymore hard choices when setting up Linux :)
The main downside to not having swap is that Linux may start discarding clean file backed pages under memory pressure, when if you had swap available it could go after anonymous pages that are actually cold.
On a related note, your program code is very likely (mostly) clean file backed pages.
Of course, in the modern era of SSDs this isn't as big of a problem, but in the late days of running serious systems with OS/programs on spinning rust I regularly saw full blown collapse this way, like processes getting stuck for tens of seconds as every process on the system was contending on a single disk pagefaulting as they execute code.
Managed over 50k servers with zero swap. Simply set overcommit ratio to 0, min_free configured based on a Redhat formula and had application teams keep some memory free. Servers ranged from 144GB ram to 3TB ram. On servers meant to be stateless app and web servers panic was set to 2 to reboot on oom which mostly occurred in the performance team that were constantly load testing hardware and apps and a few dev machines were developers were not sharing nicely. Engineered correctly OOM will be very rare and this only gets better with time as applications have more controls over memory allocation. Java will always leak, just leave more room for it.
I've had arguments with people about this for 20 years now and the most compelling case I heard involved the price of storage vs the price of RAM in the mid to late 1990s, and that this 2x represented an optimal use of money in designing a system at that point in time.
None of the answers are satisfying to me, tbh.
I install more RAM so I can swap less. If I have 8 GB, then the 2x rule means I should have a 16 GB swap file, giving me 24 GB of total memory to work with. If I then stumble upon a good deal on RAM and upgrade to 32 GB, then if I never had memory problems with 24 GB, then I should be able to completely disable paging and not have a problem. But instead, the advice would be to increase my paging file to 64 GB!?
It doesn't make any sense. At all.
It's not meant for that kind of comparison. It's a variant of Simpson's paradox. Any individual system with a fixed set of tasks needs less swap when it gets more RAM. But when you look at the aggregate of systems, the systems that have more tasks to run get more RAM to run them, and systems with fewer tasks get less RAM. And since more tasks need more swap, everything scales together (though often not linearly).
in 1997 people talking about it on the Slackware Usenet group:
It goes downhill from there..https://groups.google.com/g/alt.os.linux.slackware/c/hWy0h_S...
Curious, How much swap have you personally allocated on your personal setup?
Windows: I set min size to whatever is necessary to make RAM+swap add up to ~2 GBytes per CPU thread, to avoid problems with parallel Visual Studio builds. (See, e.g., https://devblogs.microsoft.com/cppblog/precompiled-header-pc...) Performance is typically fine with ~0.75+ GBytes RAM per job, but if the swapfile isn't preconfigured then Windows can seemingly end up sometimes refusing to grow it fast enough. Safest to configure it first
macOS: never found a reason not to just let it do whatever it does. There's a hard limit of ~100 GBytes swap anyway, for some reason, so, either you'll never run out, or macOS is not for you
Linux: I've always gone for 1x physical RAM, though with modern RAM sizes I don't really know why any more
Zero. My office workstation has 48 GB of RAM, my home computer has 64 (I went a bit overboard). I have very bad memories of swap thrashing and the computer becoming totally unresponsive until I forced a reset; if I manage to fill up so much RAM, I very much prefer the offending process to die instead of killing the whole computer.
I did similar with my 32GB laptop, but it was fairly flaky for ~4 years and I just recently put 48GB of swap on and it's been so much better. It's using over 20GB of the swap. The are cases in Linux where running without swap results in situations very similar to swapping too much.
It's funny how people think they're disabling swapping just because they don't have a swap file. Where do you think mmap()-ed file pages go? Your machine can still reclaim resident file-backed pages (either by discarding them if they're clear or writing them to their backing file if dirty) and reload them later. That's.... swap.
Instead of achieving responsiveness by disabling swap entirely (which is silly, because everyone has some very cold pages that don't deserve to be stuck in memory), people should mlockall essential processes, adjust the kernel's VM swap propensity, and so on.
Also, I wish we'd just do away with the separation between the anonymous-memory and file-backed memory subsystems entirely. The only special about MAP_ANONYMOUS should be that its backing file is the swap file.
mmap is not swap. It's using the same virtual memory mechanisms to load/dump pages to disk. The policy for when to read and write those pages is completely different.
The ghost of Multics walks yet the page tables awaiting recorporealization.
On systems with 32/64/128 GB of ram, I'll typically have a 1GB or 2GB swap. Just so that the system can page out here and there to run optimally. Depending on the system, swap is typically either empty or just has a couple hundred MB kicking around.
On what OS are you using these settings? I found that Windows will refuse to allocate more virtual memory when the commit charge hit the max RAM size even if there is plenty of physical memory left to use.
I have 64 GiB of RAM and programs would start to crash at only 25 GiB of physical memory usage in some workloads because of high commit charge. I had to re-enable a 64 GiB SWAP file again just to be able to actually use my RAM.
My understanding is that Linux will not crash on the allocation and instead crash when too much virtual memory becomes active instead. Not sure how Mac handles it.
64GB RAM, zero swap. Until recently RAM was cheap so swap made little sense when you could simply buy more RAM.
My work laptop currently has 96GB of RAM. 32 of it is allocated to the graphics portion of the APU. I have 128GB (2x) of SWAP allocated, since I sometimes do big FPGA Synthesizations, which take up 50GB of RAM on its own. Add another two IDEs and a browser, and my 64GB or remaining RAM is full.
Why was this downvoted? I’m generally curious what current recommendations for swap are too!
Edit: oh and I don’t have an actual personal system with swap configuration on it anymore to give my own answer anymore either.
same, completely fair thing to ask.
people are too negative these days :|
It's old enough that I'd put money on DEC. Any takers on that.