Re: configurability of OOM killer

Поиск
Список
Период
Сортировка
От Florian G. Pflug
Тема Re: configurability of OOM killer
Дата
Msg-id 47A4C36B.8060703@phlo.org
обсуждение исходный текст
Ответ на Re: configurability of OOM killer  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: configurability of OOM killer  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
Tom Lane wrote:
> Florian Weimer <fweimer@bfk.de> writes:
>> * Alvaro Herrera:
>>> I am wondering if we can set the system up so that it skips postmaster,
> 
>> 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.  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.

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.

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

regards, Florian Pflug


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Truncate Triggers
Следующее
От: Florian Weimer
Дата:
Сообщение: Re: configurability of OOM killer