Re: Setting oom_adj on linux?

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Alex Hunsaker <badalex(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Setting oom_adj on linux?
Date: 2010-01-08 12:07:21
Message-ID: 9837222c1001080407j2769d098m84885a6863889698@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 8, 2010 at 04:46, Alex Hunsaker <badalex(at)gmail(dot)com> wrote:
> On Thu, Jan 7, 2010 at 20:26, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Alex Hunsaker <badalex(at)gmail(dot)com> writes:
>
>> We can either drop this in core (with a lot of #ifdef LINUX added)
>
> Any thoughts on doing something like (in fork_process.c)
>
> #ifdef LINUX
> void oom_adjust()
> {
> ...
> }
> #else
> void oom_adjust() {}
> #endif
>
> So there is only one #ifdef?  It still leaves the ugly calls to the function...

Seems like a much better way, yes. Especially if we in the future want
to do this for more than one platform (if it becomes necessary).

>> or expect Linux packagers to carry it as a patch.  Given that the
>> packagers would also have to modify their init scripts to go with,
>> the patch route is not unreasonable.  Comments?
>
> Id plus +1 for core.  The problem certainly does not look to be going
> away soon (if ever).

Yeah, I think core is better. It's not like it's enough code to cause
a huge maintenance problem, I think.

Do we need to make the value configurable? I'd certainly find it
interesting to set backends to say 5 or something like that, that
makes them less likely to be killed than any old "oops opened too big
file in an editor"-process, but still possible to kill if the system
is *really* running out of memory.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2010-01-08 12:34:12 Re: Serializable Isolation without blocking
Previous Message Pavel Stehule 2010-01-08 11:51:23 Re: new full vacuum doesn't work