for some years, I've read that it's a good idea to create a swap partition having the double space of my RAM. does it still apply today? or this isn't needed anymore?
I have a server with 8 GiB of RAM and I need to create a swap partition, and I was wondering if 16 GiB was too much.
On large systems, 8GB of physical RAM, we usually allocate 2GB of swap. These are loaded database servers running Oracle or PostgreSQL. For years, I've never seen swap hit even under heavy load. Heavy load is roughly 100 to 150 users doing around 10,000 SQL reads, and maybe 2,500 writes per minute.
We also adjust the swapiness level up to discourage swapping and we turn off unneeded processes we know we don't need running. (Custom Linux builds)
Like Eddie, says above, 1x physical RAM is a good rule of thumb for anything under 4GB. I do custom Linux builds for a large, Fortune-500 company and these are the things we typically do, and we haven't had any issues in over the last 5 or so years I've been consulting for them.
On larger systems: 64bit Linux with 32GB and 64GB of RAM, these are our Oracle database servers, and we typically keep 2GB of swap around for things like Eddie points out above - idle processes will be moved to swap depending on your swapiness settings.
A seemingly timeless question. The good folks over at SlashDot discussed this a while ago. Check out what they had to say:
If I watch a 4 GB movie over a period of 2 hours, a lot of memory managers will decide that attempting to cache all of that data might be a good thing. Halfway through the movie, it will think that all those other running programs have been unused for an hour and can be safely swapped out in favor of caching more of that 4 GB file. The end result is that half your programs are swapped out after watching a movie, resulting in a sluggish system that is trashing all over the swap file.
If you have [enough RAM to run the programs you want to use on a daily basis], then there's no reason to ever use swap.
My VPS provider doesn't even provide swap space for the servers, and mine's been running along fine without it.
Most servers I see on a daily basis at work are swap-less also.
However - if you are running a JVM, make sure you have at least as much swap space as you will ever set -Xmx because of a known issue with the JVM.
In short, when the JVM needs more memory than it's currently using (but still has not hit its Xmx), it:
This means that if you swap is less than your Xmx, it can fail.
To quote the bug report
The best thing to do is increase swap size on the machines encountering this error.
I try to play it safe when working with JVMs and set swap to equal physical memory.
See the answer How much SWAP space on a high memory system? for some guidance, although your question is more general. Opinions vary widely on this, but generally people with 1 GiB of RAM or more seem to either run without swap entirely, or with 1xmemory as swap.
Even if you don't plan on using so much RAM that you'll force swapping to occur, there's some value in having at least 1xmemory as swap: It allows the operating system to swap out some things that aren't expected to be used immediately so that it can instead use that memory for disk or IO buffers, for example.
If you expect your system to be able to hibernate and then resume successfully :-) , it's probably better to allocate more space for the swap partition than the amount of physical RAM
Given the speed of modern hard disk drives, large swaps are just an invitation to thrashing. Maybe SSDs will reverse this trend, but with maybe 300MB/s maximum transfer speed for a disk, swapping in 2-4GB is going to take a good while.
In the old days (i.e.: Linux 1.2, i386, SunOS 4.x), you'd have maybe 5-15 MB of daemon processes running and anywhere from 4-32MB of RAM and so daemons that were just blocked waiting for I/O could be swapped out with no real performance hit... And they'd better since the user programs might have as few as 2-3MB of RAM available. Swapping made a lot of sense.
Now in my environment, most servers have single memory heavy workloads and RAM can be fairly accurately estimated... Swap is there for emergencies, run-away processes and so on.
The exception is for laptops and workstations that might sleep. Many OS will use the swap area to save the suspend image and in those cases, the swap must be larger then physical memory. In Linux with suspend2/tuxonice you should have 2xRAM in swap size to support suspend-to-disk.
These days if you are running a 32GB or 64GB server 4 GB of swap for the default is a safe amount. Anything larger than that is overkill with that much physical RAM available.
Ideally you wont be using the swap at all, and the 2x RAM thing is really something left over from years past.
If you are worried about it, though, I would do something like:
Max Memory Requirement - Physical Ram = Swap
I think 16GB sounds way too big, personally.
In the olden days you wanted as much as you could get, Memory consumption in modern *nix kernels is a thing of the past. The old saying was "2x your memory". Between 2GB or the amount of space the machine has in ram this day and age will take you close to where you need to be.
The swap is also used to store dumps after kernel panic. If you're interested by analysing these dumps and don't have specified another dump destination, your swap should be at least as big as your RAM.
There is no single algorithm that tells you how much swap you need. In practice, you need to put your system under the biggest load you plan to support, and find out how much resource it actually uses. Set your swap file accordingly.
For physical RAM, you should put your system under the actual "cruise" load you expect to handle, and buy accordingly. For low-latency systems you should not be swapping at all inside your cruise load (this is not the same as not having swap allocated or even in use.) A small amount of swapping may occur due to little-used system utilities performing house keeping, but by and large you should have as little swapping as possible.
Of course, you can trade off performance for lower price.
