Re: configurability of OOM killer

On Mon, 2008-02-04 at 20:06 +0000, Simon Riggs wrote:
> We make no attempt to limit our overall memory usage. We limit
> individual sessions by default, but don't prevent them from increasing
> that allocation as they choose. We don't try to reallocate memory once
> it has finished being used.
>

Did you read my post on LKML? Varying memory allocations are not the
problem here. The problem is if you have a daemon-subprocess
architecture that uses substantial amounts of shared memory.

Here's another post that explains it:
http://kerneltrap.org/mailarchive/linux-kernel/2007/2/12/54202

In that case (i.e. in the case of postgresql), it can count the same
byte of allocated memory against the postgresql daemon (1+N/2) times,
where N is the number of processes. That is plain wrong, in my opinion.

PostgreSQL does not change the shared memory allocation at all during
operation. Yet, even with a reasonable shared memory size that doesn't
cause any memory pressure, and many *idle* connections, badness()
decides (almost invariably) that the PostgreSQL daemon has more
"badness" than anything else, even if a much worse process exists. On a
box with 4GB of memory, badness() might plausibly think that

This overcounting that punishes postgresql is the problem.

Regards,
Jeff Davis