Re: configurability of OOM killer

On Fri, 2008-02-01 at 19:08 -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > This page
> > http://linux-mm.org/OOM_Killer
>
> Egad. Whoever thought *this* was a good idea should be taken out
> and shot:
>
> The independent memory size of any child (except a kernel thread) is added to the score:
>
> /*
> * Processes which fork a lot of child processes are likely
> * a good choice. We add the vmsize of the childs if they
> * have an own mm. This prevents forking servers to flood the
> * machine with an endless amount of childs
> */
>
> In other words, server daemons are preferentially killed, and the parent
> will *always* get zapped in place of its child (since the child cannot
> have a higher score). No wonder we have to turn off OOM kill.

This does look bad.

I think we should fix this problem, though I see the problem as being
Postgres not being able to set and adhere to memory limits. The OS
doesn't favour us on this point, but I think we will be ignored when we
have to explain that we don't strictly control the memory we allocate
and use.

I would like there to be a way for us to say "The server is limited to
using at most X amount of memory." There might be various ways of doing
it, but I'd like to agree that as an important goal for 8.4 dev

The benefit of doing this is that we won't have to allocate a certain
percentage of memory as contingency to avoid swapping and OOM killers.
So putting in place a memory limit will effectively increase the
available memory the server has access to and/or limit swapping, either
of which will be a performance increase.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com