Re: configurability of OOM killer - Mailing list pgsql-hackers

From Florian Weimer
Subject Re: configurability of OOM killer
Date
Msg-id 8263x7gr8c.fsf@mid.bfk.de
Whole thread Raw
In response to Re: configurability of OOM killer  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: configurability of OOM killer  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
* Tom Lane:

>> How much does that help?  Postmaster &c still need to be shut down
>> when a regular backend dies due to SIGKILL.
>
> The $64 problem is that if the parent postmaster process is victimized
> by the OOM killer, you won't get an automatic restart.

The classic answer to that is to put it into inittab. 8-/

> In most people's eyes that is considerably worse than the momentary
> DOS imposed by a kill of a child backend.  And what we now find,
> which is truly staggeringly stupid on the kernel's part, is that it
> *preferentially* kills the parent instead of whatever child might
> actually be eating the memory.

IIRC, the idea is to get the machine out of OOM land with one killed
process, even if it causes dependent processes to fail.  No matter
what you do at this point, you lose.  If you prefer the child instead
of the parent, the parent might just reattempt the fork() (which
succeeds thanks to COW), and the child runs into the same OOM
condition.

--
Florian Weimer                <fweimer@bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: configurability of OOM killer
Next
From: David Fetter
Date:
Subject: Re: Truncate Triggers