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
|
Список | 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 по дате отправления: