Re: Setting oom_adj on linux? - Mailing list pgsql-hackers

From Alex Hunsaker
Subject Re: Setting oom_adj on linux?
Date
Msg-id 34d269d41001071946u72dee551kccb1182aebfcee61@mail.gmail.com
Whole thread Raw
In response to Re: Setting oom_adj on linux?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Setting oom_adj on linux?  (Magnus Hagander <magnus@hagander.net>)
Re: Setting oom_adj on linux?  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Thu, Jan 7, 2010 at 20:26, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alex Hunsaker <badalex@gmail.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...

> 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).

>> This has some oddities like it does not reset oom to 0 for the (wal)
>> writer process.
>
> FWIW, I think that's probably a feature --- I'd vote for only resetting
> in regular backends and possibly autovac workers.

I think that makes sense +1.  In-fact thats why the patch has it as a
separate function instead of hacked into fork_process().  However its
mainly odd because IIRC I greped for all instances of fork_process()
and added the oom_adjusting to the callers.  Given that it seems the
wall writer procs should also be set to 0.  My guess is its a race
with my startup script launching postgres and then setting oom_adj. Or
maybe I missed a caller? Maybe they don't use fork_process()? Ill
check it out.


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: RFC: PostgreSQL Add-On Network
Next
From: Tom Lane
Date:
Subject: Re: damage control mode