Slashdot Mirror
How Much Virtual Memory is Enough?
whitroth asks: "Ten years ago, Received Wisdom said that virtual memory should be, on the average, two to two-and-a-half times real memory. In these days, where 2G RAM is not unusual, and many times is not that uncommon, is this unreasonable? What's the sense of the community as to what is a reasonable size for swap these days?"
My rule of thumb these days is 1.5x RAM, unless you're at 2GB, in which case I go with 2GB swap as well. This is for *gasp* Windows, though.
not creating a swap partition at all is a bad idea, imo...
you never know when some runaway process is going to eat all yer RAM and need to use swap... no matter how much RAM you've got.
I typically just make a 1 or 2 GB swap partition since I've got more than enough space to spare. I mean, back in the days when 128MB of RAM was considered a lot, and a 5GB drive was considered huge, no one would consider using 20% of their storage space for swap. Now, it's not unusual to have 300GB of storage, so what's 1% of that being used for swap?
I've also got a serious collection of 2-6GB harddrives kicking around, now, so I've been using them for swap. It's really pointless to have a 4GB partition for data, so I just use the entire 6GB drive for swap on some machines.
my primary server right now has a 4GB swap partition and 1.25GB of RAM... a piece of bad AJAX code that ran overnight wound up using all the RAM and had some seriously detrimental effects on the performance of the server. it took 25 minutes to ssh in in the morning and when I finally got in, I found that the load averages were at over 100 (I've NEVER see that before).
my point is that even if you have a LOT of RAM, it's still handy to have some spillover available.
...spike
Ewwwwww, coconut...
If you've got a 300GB primary drive, it's foolish to use a 5GB drive for your swap. While you gain the benefit of having that drive separate from the primary (and potentially not contending for the bus), those drives are so far apart technology wise that you'd probably be better off with a swap partition on your most modern disk.
That 2/5/6GB drive may have a 20MB/s sequential rate at OD and half that at ID. Modern drives more than double that sequential performance (or triple), which is what's critical when swapping in/out a large job. Many drives in that generation don't support UDMA either, and talk with PIO, meaning you get no data checksum on your transfers.
You can span generations when you're using a cost reduced modern drive (fewer heads, same formats) but the drive that was stretching to make 5GB across 6/8 heads will be a real POS compared to modern drives performance wise.
Thrashing is bad, but thrashing to a slow disk I'd think would be worse. It is even compounded since that 5GB drive is probably PATA, meaning you're going to have your swap drive and primary drive sharing a cable, which will basically nuke most of the savings of 2 disks since they'll be reselecting master/slave at almost every command.
More data, damnit!
I think it was one of the Live Journal guys at OScon that said, "If your server starts to swap, you've lost the battle".
With all of our 64bit 4GB of ram minimum hosts floating around, there is no longer a point to having swap -- if you server really is swapping, it's under a huge load and the io is making the problem worse. Let the OS kill a few processes to get it back under control
-- DrZaius - Minister of Sciences and Protector of the Faith
A modern computer should be able to accomodate every malloc upto memory+free disk space and it can't easily.
I see. So how do you get around that little address space issue? I'm quite certain a regular 32-bit PC w/ 4GB of RAM doesn't need a swapfile unless you're running Linux (and an AWFUL lot of software, or software with VERY large RAM requirements). Even in that case, it's a special kernel option, and if you can actually max your 4GB of RAM to the gills by multitasking regular, every-day software, you deserve to be penalized with sluggish performance! Okay no, but still.
Since RAM is dirt cheap anymore, everyone really should have 4GB on their 32-bit computers for the sole purpose of turning their swapfile off; it's probably the least amount of money you could spend per the increased performance in Windows.
all this swapping talk is giving me nightmares.
a few years ago, we had a customer with multiple colocated servers complaining that sometimes they crashed for no apparent reasons.
after much debugging, we figured out one of their script was leaking memory. eventually consuming all ram (2.5G) + all swap (1-2g).
now the real problem is this. those were LIVE processes so the system was constantly paging back and forth, using 90%-95% cpu just to swap the damned things in and out and starving the actual processes.
linux 2.4, linux 2.6 (early 2.6). same deal. amazingly, the distro made a difference, redhat was pure hell, debian slightly better (though still not acceptable)
freebsd was much smarter, it just killed the offending processes.it sure wasn't ideal, but at least the server was still serving its clients
to this day, i never put more than 256m as swap even on servers with 4G of ram. that's where we had the least problems.
Sure when you had 128MB of ram, and you had a 256MB swap.
But dude, my next box will have two GIGABYTES of RAM!
Every one of your usage options assumes you'll run out of physical ram. Maybe if the OS is wasting it on pointless disk caching, but don't you think the programs in memory should have priority over blind disk caching?
Lest a foolish reader believe your two options (swap immediately, or swap as lazily/late as you can) are the only two possibilities, how about swapping when, say, only 20% of physical RAM is left? That way my Firefox and Eclipse don't swap to disk and take twenty seconds to swap in when I have 500MB of GODDAMN FREE RAM!
Hey, I'm just your average shit and piss factory.
- the kernel kills the process because of a low memory condition
- an attempt to allocate memory fails. The application then handles this somehow. Since we've established that it's a lousy application, I'd guess it handles it by crashing.
Either way, the Dude^W server abides.Naturally if you actually had that much physical RAM, the process would have still gone nuts, but your server wouldn't have had to thrash its disk for every process except the prodigal son, so the performance hit probably wouldn't have been noticeable.
If you're going to be elitist, it would help to be elite.
One thing to consider is whether or not you're using tmpfs for /tmp. For performance, I recommend using tmpfs for /tmp, and basically treat the swap partition as your /tmp partition. It may seem counterintuitive, "why would it be faster than a filesystem when it's backed to disk anyway, and my filesystems caches just file if need be?" The answer is that tmpfs never needs to worry about consistency. On the kernel.org machines, we have seen /tmp-intensive tasks run 10-100 times faster with tmpfs than with a plain filesystem. The downside, of course, is that on a reboot, tmpfs is gone.
I never user more than 512Mb of swap. If you have a runaway process, you can let it live but you avoid a lot of trashing. If more than one process start consuming RAM like crazy you, actually want them to die from an out-of-mem error otherwise your whole system will grind to a halt while it spends most of its time unswaping one and the other. At 512Mb you can do a little excess of memory usage but won't go beyond what you can unswap in a time quantum (mostly).
Smarter per-process ressource quotas would probably be better and it would be nice to have a trashiness function according to the disk speed but so far 512Mb sounds like the limit between using the resset button or just taking a coffee break when you see the HD led blinking like a strobe.
It is just easier to try the approach where you consume a lot of RAM first and to re-code if it doesn't work. I work in bioinformatics and we often have huge datasets, I alway try to load the whole thing and to make the computation in RAM. Only when I get and out-of-mem error do I segment the dataset and try a smarter approach. That might explain my choice for 512Mb and the right threshold for other people might be bigger or lower but I'm pretty sure that its bellow 8Gb.
That raises the question: is swapping obsolete? Or to put it more explicitly, has the speed difference between modern CPUs and hard drives become so large, and RAM so cheap, that it's better to consider running out of RAM to be indicative of a software failure? That way you end up with a system where one or more processes may fail (or be terminated) but at least the machine remains usable and doesn't swap itself into non-responsiveness.
In my experience, the answer is yes: with 2GB of RAM in my machine, I never need to swap, and in the few instances where swapping did occur, it was because of buggy software (memory leaks) and manually terminating the offending processes is what I needed to do resolve the memory shortage. So why not just have the OS do that automatically?
Or to put it a third way, is there any situation where swapping is helpful, anymore?
I don't care if it's 90,000 hectares. That lake was not my doing.
Unfortunately the Linux system has a hard time determining what are "infrequently accessed pages" and what are useful pages to keep in the disk cache.
This is most obvious when you are copying large amounts of data, e.g. during a backup.
Say you have a 250GB disk and you copy it to another one. The system will continously try to keep the files you have read in disk cache (because you may read them again) and try to keep room for many dirty pages that still have to be written to the destination disk (because you may change them again before final writing).
All of this "(because)" is never going to happen as everything is read once and written once and then no longer needed.
But still, it will swap out running processes to make room for the above.
The net effect you see is that the source and swap disks are very busy, the destination disks sits idle long times until the kernel feels like flushing out some dirty buffers, and the other programs slow down to a crawl fighting for the swapspace.
It can be tuned with the "swappiness" variable but it remains a tough thing to control. It looks like Windows does a better job in this (not so hypothetical) case.
There should be some "file copy mode" (used during backups and other large tree copies) where it:
- discards all disk USERDATA caches immediately after use (directory and other filesystem allocation data may be kept)
- immediately writes out any written USERDATA to the destination disk, not having it populate the dirty pages until bdflush comes around to write them
- keeps re-using the same small set of buffers to pump the data from source to destination, without stealing memory from others
Issue is of course: how could this mode be enabled. It could be a special systemcall, but who would call it and where?
Personally, I would already be happy with a program like "nice" or "ionice" that would run a commandline in a special mode (e.g. with a very small buffer quota) to force such behaviour. But the world at large would of course be better serviced if this would happen automatically when lots of data are copied sequentially.
And is 1000 times faster ?
So, to answer the original question :
Optimal amount of Swap ? 0 !
Even my old PIII 1Ghz takes 2 gigs of ram. Newest system we have at the office takes 64 Gigs.
=> right now I consider the Linux systems @ work as having a problem if they use swap...
Adding just a wee bit of RAM to your system and seeing swap disappear means your perfomance just exploded on this particular task...
Best Regards,
D.
It takes 40+ muscles to frown, but only four to extend your arm and bitchslap the motherfucker
We've found that 512 Megs of swap is more than enough for our 2 and 4 Gig machines. Why even have swap? Here is an example:
1) On a system with zero swap, when apache gets slammed (say you get to the top of digg or slashdot), apache starts consuming lots of memory to handle new inbound requests. When it runs out, the machine grinds to a halt because it can't allocate more and requires a power cycle. (Setting a low max children really only helps if you are happy denying traffic to the people who are trying to see your site...it's best to plan for capacity and put quite a few servers load balanced).
2) On a system with any appreciable swap (IMHO, more than 128 Megs, up to 512 Megs), if you're monitoring the system (watch -n 1 df -h, for example) and all of a sudden it starts using swap, the machine is on the edge of dying. This gives you an early warning that maximum machine performance/throughput is occurring. You can restart apache or shut it down or similar, you can do something to temporarily lower or remove load from that machine. This doesn't give you *much* time, but it gives you some.
In our real world experience, at digg and slashdot loads you have about 10-15 seconds to stop apache once it starts swapping. After that, the performance degrades so bad that the machine becomes catatonic, the same as #1, requiring a power reset (obviously because virtual memory on HD is magnitudes slower than RAM, as numerous others have suggested). The key here is that you must realize that some swap is good for allowing unused programs to be swapped out, such as login terminals that just sit there. It's great for detecting problems, but if your heavy app is the one utilizing swap, your machine is about to crash anyway.