Max swap size?

Steven Alligood steve at bluehost.com
Thu May 29 10:15:28 MDT 2008


Stuart Jansen wrote:
> On Wed, 2008-05-28 at 20:36 -0600, Stephen Ward wrote:
>   
>> Does a 4 GB swap partition seem excessively large to anyone?
>>     
>
> Once upon a time the standard recommendation for swap was "2 x RAM" but
> the Linux virtual memory model has come a long way from original Unix.
> For example, technically swap isn't used for "swapping" these days but
> instead more efficient "paging". With shared pages, copy-on-write,
> overcommit, etc. the ancient wisdom that gave us the "2 x RAM" rule
> simply doesn't apply anymore. So an updated rule is "1.5 x RAM", but
> that still leads to crazy large swap. My personal rules is "never more
> than 1GB swap (on a server)".
>
> Of course, life is rarely simple. Linux uses swap for hibernation
> (suspend to disk). If swap is smaller than RAM, you won't be able to
> hibernate so "1.5 or 2 x RAM" on a laptop may be appropriate.
>
> As for a server, if you're actually using >1GB swap you're system will
> be so dog slow it'll be unusable. Unless of course we're talking a very
> long running server and a program that allocates lots of memory, shoves
> data into it, but rarely reads from it. Not very realistic, and not
> great software design, but one possible reason for creating a huge swap
> device.
>
> Although it is possible for Linux to run without any swap at all, doing
> so is less efficient. The Linux kernel will manage memory more
> aggressively when it knows that swap is available in an emergency.
>
> And while we're on the topic of Linux memory management, I'm going to
> mention a surprising feature that many don't know about: the OOM killer.
> When the kernel is about to run out of memory (OOM) it has only two
> options (1) dead lock hard or (2) kill a process to free memory.
> Obviously #1 isn't a good options, so Linux does #2. The kernel does
> it's best to pick either the process causing the problem, or an
> unimportant process, but it sometimes guesses wrong. You can turn off
> the OOM killer, but you probably shouldn't. Instead, just make sure you
> have enough RAM+swap.
>   

In my experience, the OOM killer almost ALWAYS gets it wrong, and you 
have to reboot anyway.  Neat idea, generally flawed.  Some of the 
changes in the newer kernels coming out are supposed to let you tune 
some of how it does it's thing.  We'll see if it's any better.


As for swap, I keep a bunch in systems as secondary swap (you can tune 
it to use your main 1 GB swap, and only use the 4 GB swap on the slow 
drive if it runs out, rather than striping the swap partitions).  In 
some cases (not anywhere near all by any definition of 'all') the OOM 
and the box spiraling out of control all work together and I can get in 
and kill something large myself before it completely hangs and requires 
a reboot.  This allows me to see what is killing it in the first place 
and fix it.  Much better than guessing after a reboot.  When it actually 
works, it is worth the relatively cheap 4 GB of space on the slow drive.

As for how much you *should* have is a different matter.  In Solaris, 
when a panic occurs the system core dumps ALL of it's RAM and shoves it 
into swap.  On boot, it looks for that stuff in swap before it 
initializes swap, and dumps it to a useful file if it exists.  Linux 
doesn't seem to have anything like that, so I generally match RAM.  The 
hibernation to swap thing is interesting.

Also remember that shared memory uses swap space for addressing and some 
management.  If you get rid of swap, you change how the system does it's 
shared memory management, often quite a bit slower.




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
Url : http://plug.org/pipermail/plug/attachments/20080529/0c881276/attachment.bin 


More information about the PLUG mailing list