From: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Florian Weimer <fweimer(at)bfk(dot)de>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: configurability of OOM killer |
Date: | 2008-02-02 19:24:27 |
Message-ID: | 47A4C36B.8060703@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Florian Weimer <fweimer(at)bfk(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Weimer | 2008-02-02 19:39:15 | Re: configurability of OOM killer |
Previous Message | Tom Lane | 2008-02-02 19:23:40 | Re: Truncate Triggers |