Re: configurability of OOM killer - Mailing list pgsql-hackers

From Florian G. Pflug
Subject Re: configurability of OOM killer
Date
Msg-id 47A4D741.1060604@phlo.org
Whole thread Raw
In response to Re: configurability of OOM killer  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: configurability of OOM killer  (Martijn van Oosterhout <kleptog@svana.org>)
List 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: configurability of OOM killer
Next
From: "Pavel Stehule"
Date:
Subject: clone varlena function