From: Magnus Hagander on
On Mon, Jan 4, 2010 at 17:55, Alvaro Herrera <alvherre(a)commandprompt.com> wrote:
> Magnus Hagander wrote:
>
>> Right. Which is why I like the idea of disabling the OOM killer for
>> the *postmaster*, but not the regular backends. Gives it a chance to
>> recover. It's not nice, but it's better than nothing.
>
> It doesn't sound like the init script can reenable the killer for the
> child processes though.  So, if there's anything that the core code
> ought to do, is re-enable OOM-killer for postmaster children, after
> being disabled by the initscript.

Yeah, that's why the backend code would need to be involved.


> BTW, is it possible for pg_ctl to disable OOM-killer?  I guess not,
> since it's not run by root ...

No, it has to run as root.


> Is there a way to disable memory overcommit for particular processes?
> That would be very useful -- just disable overcommit for all Postgres
> processes, and there shouldn't be much need to enable the killer for
> backends.

Not that I've been able to find.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on
Alvaro Herrera <alvherre(a)commandprompt.com> writes:
> Is there a way to disable memory overcommit for particular processes?

I would think not --- the very essence of overcommit is that you're
promising more total memory than the system has got, and that's
inherently a global proposition.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Alvaro Herrera on
Magnus Hagander wrote:
> On Mon, Jan 4, 2010 at 17:55, Alvaro Herrera <alvherre(a)commandprompt.com> wrote:

> > BTW, is it possible for pg_ctl to disable OOM-killer? �I guess not,
> > since it's not run by root ...
>
> No, it has to run as root.

We could at least make it work on Windows, since it is often run as
Administrator and drops privileges afterwards ...

.... oh, wait ...

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on
Magnus Hagander <magnus(a)hagander.net> writes:
> I realize this is a very platform-specific thing, but should we
> consider setting the value of /proc/<pid>/oom_adj when running on
> linux? See:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/proc.txt;h=220cc6376ef80e0c9bcfec162d45552e729cdf5a;hb=45d28b097280a78893ce25a5d0db41e6a2717853

One interesting thing I read there is:

Swapped out tasks are killed first. Half of each child's memory size is
added to the parent's score if they do not share the same memory.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This suggests that PG's shared memory ought not be counted in the
postmaster's OOM score, which would mean that the problem shouldn't be
quite as bad as we've believed. I wonder if that is a recent change?
Or maybe it's supposed to be that way and is not implemented correctly?

BTW, the given link shows only chapter 1, see

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/filesystems/proc.txt;hb=45d28b097280a78893ce25a5d0db41e6a2717853

for the whole file.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: "Kevin Grittner" on
Tom Lane <tgl(a)sss.pgh.pa.us> wrote:

> This suggests that PG's shared memory ought not be counted in the
> postmaster's OOM score, which would mean that the problem
> shouldn't be quite as bad as we've believed. I wonder if that is
> a recent change? Or maybe it's supposed to be that way and is not
> implemented correctly?

I've wondered about that based on my experience. When I found that
memory leak back in 8.2devel, running on a SLES 9 SP 3 system, the
OOM killer killed the offending backend rather than the postmaster,
although it took out a couple Java middle tier processes before
starting in on PostgreSQL.

-Kevin

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers