Slashdot Mirror
How Big Should My Swap Partition Be?
For the last 10 years, I have been asking people more knowledgeable than I, "How big should my swap be?" and the answer has always been "Just set it to twice your RAM and forget about it." In the old days, it wasn't much to think about — 128 megs of RAM means 256 megs of swap. Now that I have 4 gigs of RAM in my laptop, I find myself wondering, "Is 8 gigs of swap really necessary?" How much swap does the average desktop user really need? Does the whole "twice your RAM" rule still apply? If so, for how much longer will it likely apply? Or will it always apply? Or have I been consistently misinformed over the last 10 years?
I have an Eee 901. It has 1GiB of RAM and 20GB of disk space. A swap partition on the 'twice your RAM' rule would be far from trivial.
I decided to be bold and installed Hardy with no swap partition. It seems to work just fine so far; Firefox greys out for a few seconds sometimes while loading pages, which might have to do with my reckless configuration, but on the whole it's pretty snappy.
As for my desktop PC, it has 4GiB of RAM. I followed the traditional rule when I installed on that. I don't think that swap partition has ever even been used.
Real Daleks don't climb stairs - they level the building.
Delaying is largely the point as I see it. If you're out of ram and it's eating into the swap, things are going to slow to a crawl and you'll know something is wrong, so you can look for, find, and kill whatever is running amok before it consumes all and triggers a panic/BSOD/etc.
upon the advice of my lawyer, i have no sig at this time
consider using a swap file for your setup id recommend 256mb of swap, with 1.25gb of ram (apart from when i left wireshark running for toolong) ive not seen it creep above ~100mb for long.
IranAir Flight 655 never forget!
Maybe we should be asking "should we even bother with swap files?". I took a class on that where we calculated the steps it takes to get the final memory address in a paged memory system. It was something like 36 steps per address! We had PDEs, PTEs, convert this, change that. I didn't grok all the steps, but I do know there were a lot of them. I know 36 steps per little itty bitty piece of memory is a lot, even if you are a very fast CPU, when you have to do this hundreds of millions of times.
Back in the day, it made sense to convince your programs you had an extra 100 megs of RAM, because a lot of programs needed that and didn't have it in memory. Today, memory is more abundant than things we would really need it for at the non-industrial level. I don't personally have any non-industrial applications that will fill up 4 gigs of RAM. Even Vista + WoW won't take up all that.
So, and my professor suggested this, maybe the ideal swap size is ZERO. What if your operating system just operated under the concept of "If you can't fit it in 4 gigs, tough. Just wait until memory is free. I'm not even going to bother to split memory into pages because I'm always going to use RAM, not a hard drive page. Case closed." We could save so much overhead and complexity if we just admit that we never need to pretend hard drive is RAM. With 4 gigs or more of RAM, why even have a glacial slow hard drive in the mix?
I have 64 GB of RAM and my swap partition is the same size at 64 GB. I thought 128 GB is a little excessive. What I would really like is if someone would make up an IDE interface to RAM modules and build a large amount of such RAM into the form factor of a hard disk drive. Then, you could populate this RAM-based "hard drive" with the necessary data during startup, and use it for swap and for all of your system's various "temp" folders. This would make swapping (and temp stuff) extremely fast to access, and more importantly, it would eliminate the need to encrypt your swap and/or temp partitions, as the data would simply disappear when power is removed. So when the agents (including Agent Smith) come to bust down your door, all you do is pull the plug and voila! Your secrets are safe. :-)
McCain/Palin '08. Now THAT's hope and change!
In early Unixes (SunOS, e.g.), the memory manager was dumb and preallocated swap space sufficient to swap your entire process out if it became necessary, and it really did want contiguous. Running out of swap was common, even if it was really never used, and the "rule" to avoid that problem was 2xRAM. Further, if you had two swap partitions, or a partition and a file, your process stayed in whatever swap it started in and did not split across both. You could be out of swap space and still have a completely empty swap file.
Memory managers have gotten smarter, mapping smarter, and now swap is only used when it really is necessary. Pages that are not dirty don't get swapped, they get reloaded from the disk they came from. Pages that are swapped are often used soon enough that they never leave the RAM buffers.
Yesterday, I had a user come to me saying he was getting an "out of memory" error from Matlab. Matlab is notorious for not garbage collecting when it needs to. His Matlab process had 800Mb of resident memory, even though he said he had just 300Mb of data. The kicker? Somehow, over the last couple of years, the swap file I had created to extend the 512Mb swap partition had gotten lost. Dunno where it went, just not there. He had 512Mb of swap, and most of that wasn't being used. Never noticed it until yesterday. His 2Gb of RAM was sufficient for what he was doing.
It's a case of people who learned early just doing what they know works, telling youngsters the "rule" so they do the same thing.
Oh dear FSM, Please for the sake of everyones sanity, NEVER LET WINDOWS GROW THE SWAPFILE! besides the fact it it will fragment the pagefile, it will also completely lock up the computer for X amount of time... right when you need it most! ...it ALWAYS happens at a bad time.
Modding Trolls +1 inciteful since 1999
Perhaps you'd like to tell us whether a GB is base 2 or base 10 then.
You obviously aren't worth your SALT!
Remember kids, it DEPENDS!
Bandwidth? Base 10 -- always has been.
ROM? Base 2 -- always has been -- and traditionally in bits, not bytes.
RAM? Base 2, and bytes.
Hard disk? Base 10 in the manufacturer's specs, base 2 in the OS display. Always has been that way, always will be.
Floppies? Base 2 until you get to MB, where 1MB = 1000 base 2 KB (seriously).
Clock speeds? Base 10, always has been, always will be.
Flash? Who knows.
Isn't it great that we have such an easy, convenient system that is focused around the needs of us humans, and not the needs of the computers (who don't care in the slightest).
I have seen the future, and it is inconvenient.
It does hurt to allocate a couple of gigs of swap.
:). If you have lots of RAM and are too lazy to guess, set F=0.
I use swap only to tell me that I'm low on RAM. Basically once the machine starts using swap and getting slightly slow- it means I'm low, then I can try to shut down stuff (without it behaving otherwise strangely, or dying abruptly).
Here's how I suggest you figure out _roughly_ how much swap you need.
1) Figure out the amount of Virtual Memory your programs and services _allocate_ without really _using_ - call this F. There are some programs that allocate hundreds of MB of memory but never use it. But note that there are some programs that allocate lots of memory and may use it
2) Figure out your drive throughput for swap access (swap in + swap out)- this is often related to random access throughput - and for a typical hard drive it could be in the order of magnitude of 10MB/sec - call this M. Note that many flash drives have pathetic random write speeds of 4MB/sec (or even less!).
3) Figure out the time you are willing to wait for stuff to swap in and out (e.g. time to get an ssh prompt- call this T.
Swap = F + T * M.
So for example, if you have programs that allocate a total of 100MB and never use it, and your drive swap throughput is 10MB/sec and the amount of time you're willing to wait is 15 seconds.
Swap = 100MB + 15 sec * 10MB/sec = 250MB.
As you can see allocating gigabytes can hurt - since it'll take days to swap in and out processes that are using gigabytes of swap. You'll run out of time before you run out of swap, and when that happens somebody will do a hard shutdown of the machine - and that means ALL processes will be abnormally terminated, rather than just one.
Yes, there are cases where the offending program might not keep accessing all of that swap, but when a program misbehaves like that, you'd rather find out sooner rather than have to shutdown the whole computer (because it takes ages to respond).
Running programs from swap is best reserved for those who wish to experience the 1950s drum memory days. If you want to do retrocomputing keep in mind that memory speeds are now much faster than disk speeds, whereas in the 1950s memory speed = drum speed, and most modern programs assume modern memory speeds.
But then people might find out it was Realtek or Nvidia fucking up and won't be able to blame Micro-dollars-oft.
You can't spell goatse without Gates and a big O you know!
3laws: No freebies, no backsies, GTFO.
Until a few months ago, I regularly answered this question for enterprise Linux customers, so I humbly submit that my anecdotal experience is marginally more informed than most here.
Memory capacity and bandwidth is improving orders of magnitude faster than disk throughput and latency, and this has been true for decades. If the workload stays the same, you should generally have a lower swap/RAM ratio on newer hardware than older hardware, because it's so much cheaper these days to add more RAM, and adding more swap can actually make your system slower when you finally start using it, because it takes much longer to page in 8 GB of data from disk than 4 GB.
The kernel virtual memory (VM) subsystem is a briar patch of carefully-tuned code which, whenever altered, almost always causes a regression for some obscure combination of hardware and software that someone somewhere cares an awful lot about. This is not due to inherent bugginess, but rather the fact that the VM is essentially in the business of predicting the future, which is mathematically impossible to always get right. As a result, developers tend to be very conservative about VM optimizations, so the VM tends not to adjust its assumptions about hardware quite as quickly as the hardware itself changes.
The upshot of all of this is that as time goes by, swap becomes more of a lifeline for worst-case memory shortages and less of an optimization to make the system behave as though it had more memory. This is not to say you should do without it completely, but the ratio tends to keep going down. For desktop use, I've been using a 1:1 ratio for a while, and honestly, that's probably too large for how I use it. Digging out of 2X swap takes *more* than twice as long as digging out of 1X swap, because you end up thrashing back through the stuff you've already paged in and out before you get to the rest. Think of the Tower of Hanoi problem as an extreme worst case. Beyond a certain point, you really want the kernel to refuse memory allocations and/or invoke the OOM-killer to kill off your misbehaving app and restore performance for the rest of the system.
Whatever you do, you shouldn't go completely swapless unless you really know what you're doing. Having just a few hundred megabytes of swap on a huge 4-socket server gives you a buffer against out-of-memory conditions that could bring down the whole system. In this extreme case, it's actually *good* that swap is slower than RAM, because it stalls userspace page dirtying while waiting for I/O, leaving the CPU free for the kernel to scan for pages that should be paged out, faster than userspace can dirty them.
If you're stuck on a small system you can't upgrade, having a high swap/RAM ratio might still make sense, but modern hardware tends to have much more and faster RAM and only slightly faster I/O.
If you've got a carefully tuned database server that's reserving much of its memory for hugepages, you should start your calculation with the amount of *swappable* RAM, which is the RAM not set aside for hugepages. So, if you've got 16 GB of RAM, and 12 GB reserved in hugepages, you only want swap proportional to 4 GB of RAM.
The proportion itself is still a delicate matter. On a desktop system where you may open lots of applications, and then leave some of them idle for days while using other resource-intensive programs, it may make sense to go as high as 1x. On servers where latency is important, you probably don't want to go higher than 0.25. If you've got a batch compute system where you feed it a huge amount of work and expect it to be done when you come back several hours later, it can still make sense to have upwards of 2x as much swap as RAM. It might be sluggish to give you a login prompt, but that doesn't necessarily mean it's thrashing inefficiently if you have a fairly sequential access pattern.
If all of this confuses you, and your distribution recommends 2 GB by default at install time, odds are you'll do okay with that, at least for the near future. Once solid-state storage becomes mainstream, most of what I've said in this post will be completely obsolete.
There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
In that case, why can't I just let Windows XP or Vista manage the virtual memory size by itself? I don't see why I should need to establish a fixed size when Windows can manage it dynamically.
I have yet to see a version of Microsoft windows that does not end up with a hopelessly fragmented swap file over time. And if you let windows dynamically use space for swap, you're just asking for an even more hopelessly fragmented drive as it starts grabbing space anywhere it can find some to expand the swap file.
On my own windows installs I have brought some old-school unix (FreeBSD in particular) methodology to partitioning, and I make a partition just for swap (still 2x my total memory size). Of course in windows you still have to partition it, but I just don't write anything to it myself, and tell windows to only swap to that partition. Then my main partition doesn't end up as terribly fragmented.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.