[ec2] swap?

[Jeff Koftinoff]

On 2009-Jul-26, at 2:55 AM, Robert Coup wrote:

> On Sun, Jul 26, 2009 at 11:33 AM, Eric Hammond  
> <ehammond at thinksome.com> wrote:
>
> In my own production servers I prefer to run with plenty of memory and
> no swap.
>
> Likewise, certainly I don't run production machines with any more  
> than 256MB of swap, most have none. Reason being is once all the RAM  
> is consumed a process has gone haywire and needs to die. The more  
> swap there is the longer the time until the OOM-killer steps in.  
> Until then everything on the box grinds to a halt, new connections  
> just hang, there's no way to log in (15mins+ to a shell), etc. With  
> no swap, the out-of-memory killer steps up immediately and kills off  
> the hungry process. I'd much rather such an errant process dies (and  
> is restarted by monitoring) than the box grind to a halt.
>
> Note this is a bit different from lots of processes (eg. apache  
> workers) slowly growing over time until there's no memory left. We  
> watch out for that via monitoring as well.
>


Very good points, and neat idea for having 256 MB of swap.

The problem with relying on the OOM-killer is that it sometimes does  
the wrong thing.

For instance, if you have one task that is misbehaving and eats up  
most but not all of your memory.  Then later, your mysql or postgresql  
gets a big query and needs to allocate a little bit more memory.  When  
the database tries to use that memory it will get killed by the OOM  
killer and your misbehaving task is still running.

In addition, it is important to note that in a typical linux system,  
memory is not allocated at the 'malloc()' or 'new' call. Only virtual  
memory is allocated there. Actual memory pages are only allocated at  
the point that they are used.  The problem with this of course is that  
malloc() and new hardly ever return 0 or throw bad_alloc exceptions -  
they just get killed when they try to use the memory that was  
successfully allocated!

Anyways, once the OOM killer kicks in, all bets are off on having your  
system being recoverable...

jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/ec2/attachments/20090726/c395d09f/attachment.htm