Re: configurability of OOM killer
От
Florian Weimer
Тема
Re: configurability of OOM killer
Дата
Msg-id
8263x7gr8c.fsf@mid.bfk.de
Ответ на
Re: configurability of OOM killer (Tom Lane)
Список
Дерево обсуждения
configurability of OOM killer Alvaro Herrera <alvherre@commandprompt.com>
Re: configurability of OOM killer Tom Lane <tgl@sss.pgh.pa.us>
Re: configurability of OOM killer Simon Riggs <simon@2ndquadrant.com>
Re: configurability of OOM killer Jeff Davis <pgsql@j-davis.com>
Re: configurability of OOM killer Simon Riggs <simon@2ndquadrant.com>
Re: configurability of OOM killer Jeff Davis <pgsql@j-davis.com>
Re: configurability of OOM killer Simon Riggs <simon@2ndquadrant.com>
Re: configurability of OOM killer Jeff Davis <pgsql@j-davis.com>
Re: configurability of OOM killer Simon Riggs <simon@2ndquadrant.com>
Re: configurability of OOM killer Tom Lane <tgl@sss.pgh.pa.us>
Re: configurability of OOM killer Simon Riggs <simon@2ndquadrant.com>
Re: configurability of OOM killer Decibel! <decibel@decibel.org>
Re: configurability of OOM killer Ron Mayer <rm_pg@cheapcomplexdevices.com>
Re: configurability of OOM killer Decibel! <decibel@decibel.org>
Re: configurability of OOM killer "Dawid Kuroczko" <qnex42@gmail.com>
Re: configurability of OOM killer Simon Riggs <simon@2ndquadrant.com>
Re: configurability of OOM killer Martijn van Oosterhout <kleptog@svana.org>
Re: configurability of OOM killer Simon Riggs <simon@2ndquadrant.com>
Re: configurability of OOM killer Tom Lane <tgl@sss.pgh.pa.us>
Re: configurability of OOM killer "Markus Bertheau" <mbertheau.pg@googlemail.com>
Re: configurability of OOM killer Simon Riggs <simon@2ndquadrant.com>
Re: configurability of OOM killer Decibel! <decibel@decibel.org>
Re: configurability of OOM killer Alvaro Herrera <alvherre@commandprompt.com>
Re: configurability of OOM killer "Dawid Kuroczko" <qnex42@gmail.com>
Re: configurability of OOM killer Martijn van Oosterhout <kleptog@svana.org>
Re: configurability of OOM killer "Zeugswetter Andreas ADI SD" <Andreas.Zeugswetter@s-itsolutions.at>
Re: configurability of OOM killer Alvaro Herrera <alvherre@commandprompt.com>
Re: configurability of OOM killer Ron Mayer <rm_pg@cheapcomplexdevices.com>
Re: configurability of OOM killer Jeff Davis <pgsql@j-davis.com>
Re: configurability of OOM killer Tom Lane <tgl@sss.pgh.pa.us>
Re: configurability of OOM killer Jeff Davis <pgsql@j-davis.com>
Re: configurability of OOM killer Andrew Dunstan <andrew@dunslane.net>
Re: configurability of OOM killer Ron Mayer <rm_pg@cheapcomplexdevices.com>
Re: configurability of OOM killer Florian Weimer <fweimer@bfk.de>
Re: configurability of OOM killer Tom Lane <tgl@sss.pgh.pa.us>
Re: configurability of OOM killer "Florian G. Pflug" <fgp@phlo.org>
Re: configurability of OOM killer Andrew Dunstan <andrew@dunslane.net>
Re: configurability of OOM killer Tom Lane <tgl@sss.pgh.pa.us>
Re: configurability of OOM killer "Florian G. Pflug" <fgp@phlo.org>
Re: configurability of OOM killer Martijn van Oosterhout <kleptog@svana.org>
Re: configurability of OOM killer Tom Lane <tgl@sss.pgh.pa.us>
Re: configurability of OOM killer Andrew Dunstan <andrew@dunslane.net>
Re: configurability of OOM killer Gregory Stark <stark@enterprisedb.com>
Re: configurability of OOM killer Florian Weimer <fweimer@bfk.de>
Re: configurability of OOM killer Tom Lane <tgl@sss.pgh.pa.us>
Re: configurability of OOM killer Florian Weimer <fweimer@bfk.de>
Re: configurability of OOM killer Dimitri Fontaine <dfontaine@hi-media.com>
* 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 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 по дате отправления