From: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, 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 20:49:05 |
Message-ID: | 47A4D741.1060604@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Another thought is to tell people to run the postmaster under a
> per-process memory ulimit that is conservative enough so that the
> system can't get into the regime where the OOM killer activates.
> ulimit actually behaves the way we want, ie, it's polite about
> telling you you can't have more memory ;-).
That will only work if postgres in the only service running on the
machine, though, no? If the postmaster and it's chilren use up 80% of
the available memory, then launching a forkbomb will still lead to the
postmaster being killed (Since it will get the most points). Or at least
this is how I interpret link posted originally.
And *if* postgres is the only service, does setting a ulimit have an
advantage over disabling memory overcommitting?
AFAICS, memory overcommit helps if a program creates 50mb of mosty
read-only data, and than forks 10 times, or if it maps a large amount of
memory but writes to that block only sparsely. Since postgres does
neither, a dedicated postgres server won't see any benefits from
overcommitting memory I'd think.
regards, Florian Pflug
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2008-02-02 21:23:10 | clone varlena function |
Previous Message | Tom Lane | 2008-02-02 20:17:29 | Re: configurability of OOM killer |