Re: configurability of OOM killer

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Florian G. Pflug wrote:
>> Maybe we should just react equally brute-force, and just disable the
>> OOM-Killer for the postmaster if we're running on linux. It seems that
>> something like "echo -17 > /proc/<pid>/oom_adj" should do the trick.

> That will protect the postmaster but none of the children. And it will
> be very fragile, as only root can do it.

However, init-scripts do run as root, so this is something that the RPM
packages could theoretically do. I wonder whether it would be seen as
good packaging practice ;-)

Not protecting the children is probably sane, since it's perfectly
possible for one of them to blow up memory-wise. If you're going
to protect them then there's little point in enabling the OOM killer
at all.

>> And maybe add a note to the docs telling people to disable memory
>> overcommit on dedicated database servers if that isn't already there...

> It is there, and has been for years.

Another thought is to tell people to run the postmaster under a
per-process memory ulimit that is conservative enough so that the
system can't get into the regime where the OOM killer activates.
ulimit actually behaves the way we want, ie, it's polite about
telling you you can't have more memory ;-).

The problem with that is that the DBA has to do the math about what he
can afford as a per-process ulimit, and it seems a fairly error-prone
calculation. Is there any way we could automate it, in whole or
in part? We are certainly capable of setting the ulimit ourselves
if we can figure out what it should be.

regards, tom lane