Interesting that most voters on the page believes that zero swap is a good thing. Taking a quick look at my own servers and desktop usage it fits perfectly in table 2, ie. the same as the authors and Fedora's recommendation.
In what situation would you be 100 % sure you could never run out of RAM or would rather have an OOM situation than using swap? Seems extremely counter-intuitive to me.
When you get out of RAM, the computer becomes completely unusable for an unspecified amount of time and you end up force rebooting after minutes of frustration. I'd rather have the OOM killer step up and keep things in order.
The thing is that you don't get "out of memory errors" you get the kernel to almost randomly choose a process and sacrifice it in order to free ram.
If the chosen process is a database... That's not funny. At all.
Edit: you could adjust the oom score to avoid Linux killing important process, but I don't want to discover if Linux is actually going to follow the oom score or just "keep it in mind" when choosing a process to sacrifice.
When you have 256 gigabytes of RAM 8 gigs of swap isn't going to move the needle on OOM and it will put you at risk of having things you didn't want swapped out swapped preemptively. At various points in history Linux would swap out your application in favor of cached filesystem data even with kernel tunables set appropriately. This may have changed, it may not, but who cares because swap just isn't that useful when you have a lot of RAM.
Also swap on spinning disk is 100% pointless in most cases and many servers are still on spinning disk only as is appropriate for their usage.
On a server running data intensive applications you generally have your memory divided pretty cleanly into scratch space and working set you absolutely don't want swapped out, and data on disk that is swapped out either via a buffer pool or the page cache. The application manages which category memory utilization falls into in order to ensure consistent performance and to avoid things like event loop threads blocking on swap or threads holding locks blocking on swap.
Swap works great on desktops now that SSDs are a thing and it regularly cleans up after messy applications on my MacOS laptop. Compressed memory is also great. Granted performance on my Mac is abysmal, browser tabs take seconds to open and accept input, apps need to warm up after a context switch, but it beats opening and closing stuff constantly.
Before I got an SSD, I'd rather have the OOM handle it than risk swapping to disk. Now that I have an SSD, swapping isn't a big deal, but I also don't bother hibernating, so I just make sure I have a fair amount of swap (up to 8GB).
These estimates are bizarrely high, in my experience.
Laptop: RAM + 1GB.
Laptops hibernate, and they need space for that. The extra gig is for temp space during the hibernate/restore time periods.
Desktop: 1GB.
Linux will often use some swap space when available for libraries which are technically loaded into memory but will never actually be called again. This is typically in the 100-300MB range.
Server: minimum 1GB -> 1/16 RAM -> maximum 8GB
Servers shouldn't swap; as soon as they do, you should either be adding more RAM or figuring out what went wrong. In the meantime, a little swap will let you ride out a short storm. If you're actively swapping on 8GB of RAM, you have a more serious problem anyway.
Assume that these numbers will change, mostly under the impact of new storage technology. SSD made swapping much less nasty for the system's performance, but at a more serious cost to the storage's lifetime.
These are close to optimal recommendations. They capture the modern truth that swap is too slow to actually transfer to and from, but that it can enlarge the effective memory slightly by providing a place to park very rarely used data.
However, this is only a minor optimization and mostly it is not worth the trouble of configuring it. On servers especially I prefer zero swap. The mere existance of swap can cause pain as inevitably some new admin will come along and insist on monitoring swap use and sending alerts when it becomes full. "We have critical situation: we are using 99% of (8GB) swap on the database host (1TB main memory), I'm rebooting it". True story.
I'd like to see some differentiation between a server and a desktop, since the correct answer varies wildly.
On app servers I'll often do no swap because I don't want the performance hit of an unexpected swap. I have real time memory monitoring and self-healing in place to prevent OOM. On a bastion server that isn't handling user traffic I probably will add a swap so I can get by with lower total memory on the box, and have a buffer before the OOM killer starts hacking away.
On desktop I'll often have a large swap that's there mostly so I don't get to that horrible locking hell when the OOM killer starts mercilessly hacking processes I care about while leaving ones I don't alive. This gives me time to handle it myself. Also I may want to hibernate.
So tl;dr: the rules all change depending on what the box is used for. Asking this question generally is like saying, "what should the towing capacity of my car/truck be?" Well the next question is: what are you towing? do you care about fuel efficiency, etc.
The 'right' answer is to stop allocating swap in a separate partition, and share swap space with the filesystem.
Whether you do this with an LVM, or by pinning files and swapping to their underlying extents is less important. But assuming at system setup time that you can bound the amount of swap that will be required in the future to support some specific workload is silly, and in order to avoid being wrong, you have to penalise most systems most of the time.
It does, but your suspend-to-disk tool has to support it.
(Linux supports discontiguous swap – and therefore suspend-to-disk – in general. The suspend-to-disk mechanism just needs to know where the suspend space starts, and the mechanism of determining that varies by filesystem.)
My 8gig ram linux system runs out of ram and sometimes crashes when I run Android Studio. It refuses to use the default swap file on the ssd hard drive.I created a 16 gig swap file and set the swappiness value to 100. It only uses a few megabytes of the swapfile sometimes and still runs out of memory when I run Android Studio and then crashes. I ordered 16 gig ddr4 ram today and will remove the current swap file when the ram arrives. Seems like the only solution. I don't have time to burn another night reading up on this.
18 comments
[ 3.7 ms ] story [ 62.6 ms ] threadIn what situation would you be 100 % sure you could never run out of RAM or would rather have an OOM situation than using swap? Seems extremely counter-intuitive to me.
If the chosen process is a database... That's not funny. At all.
Edit: you could adjust the oom score to avoid Linux killing important process, but I don't want to discover if Linux is actually going to follow the oom score or just "keep it in mind" when choosing a process to sacrifice.
Also swap on spinning disk is 100% pointless in most cases and many servers are still on spinning disk only as is appropriate for their usage.
On a server running data intensive applications you generally have your memory divided pretty cleanly into scratch space and working set you absolutely don't want swapped out, and data on disk that is swapped out either via a buffer pool or the page cache. The application manages which category memory utilization falls into in order to ensure consistent performance and to avoid things like event loop threads blocking on swap or threads holding locks blocking on swap.
Swap works great on desktops now that SSDs are a thing and it regularly cleans up after messy applications on my MacOS laptop. Compressed memory is also great. Granted performance on my Mac is abysmal, browser tabs take seconds to open and accept input, apps need to warm up after a context switch, but it beats opening and closing stuff constantly.
Laptop: RAM + 1GB.
Laptops hibernate, and they need space for that. The extra gig is for temp space during the hibernate/restore time periods.
Desktop: 1GB.
Linux will often use some swap space when available for libraries which are technically loaded into memory but will never actually be called again. This is typically in the 100-300MB range.
Server: minimum 1GB -> 1/16 RAM -> maximum 8GB
Servers shouldn't swap; as soon as they do, you should either be adding more RAM or figuring out what went wrong. In the meantime, a little swap will let you ride out a short storm. If you're actively swapping on 8GB of RAM, you have a more serious problem anyway.
Assume that these numbers will change, mostly under the impact of new storage technology. SSD made swapping much less nasty for the system's performance, but at a more serious cost to the storage's lifetime.
I'm happy to let the kernel decide whether it wants to use some of the RAM for disk buffer rather than committed memory.
However, this is only a minor optimization and mostly it is not worth the trouble of configuring it. On servers especially I prefer zero swap. The mere existance of swap can cause pain as inevitably some new admin will come along and insist on monitoring swap use and sending alerts when it becomes full. "We have critical situation: we are using 99% of (8GB) swap on the database host (1TB main memory), I'm rebooting it". True story.
On app servers I'll often do no swap because I don't want the performance hit of an unexpected swap. I have real time memory monitoring and self-healing in place to prevent OOM. On a bastion server that isn't handling user traffic I probably will add a swap so I can get by with lower total memory on the box, and have a buffer before the OOM killer starts hacking away.
On desktop I'll often have a large swap that's there mostly so I don't get to that horrible locking hell when the OOM killer starts mercilessly hacking processes I care about while leaving ones I don't alive. This gives me time to handle it myself. Also I may want to hibernate.
So tl;dr: the rules all change depending on what the box is used for. Asking this question generally is like saying, "what should the towing capacity of my car/truck be?" Well the next question is: what are you towing? do you care about fuel efficiency, etc.
Whether you do this with an LVM, or by pinning files and swapping to their underlying extents is less important. But assuming at system setup time that you can bound the amount of swap that will be required in the future to support some specific workload is silly, and in order to avoid being wrong, you have to penalise most systems most of the time.
Does hibernate/suspend-to-disk work with non-partition swap? IIRC that is/was a limitation.
(Linux supports discontiguous swap – and therefore suspend-to-disk – in general. The suspend-to-disk mechanism just needs to know where the suspend space starts, and the mechanism of determining that varies by filesystem.)
See https://www.kernel.org/doc/Documentation/power/swsusp.txt