Setting oom_adj on linux?
in [PgSql]
|
Prev: [HACKERS] Setting oom_adj on linux?
Next: [HACKERS] What's the current theory about derived files in VPATH builds?
From: Andrew Dunstan on 9 Jan 2010 17:04 Peter Eisentraut wrote: > On fre, 2010-01-08 at 11:37 -0500, Tom Lane wrote: > >> Alex Hunsaker <badalex(a)gmail.com> writes: >> >>> On Fri, Jan 8, 2010 at 07:27, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >>> >>>> Then, somebody who wants the feature would build with, say, >>>> -DLINUX_OOM_ADJ=0 >>>> or another value if they want that. >>>> >>> Here is a stab at that. >>> >> Anybody have an objection to this basic approach? I'm in a bit of a >> hurry to get something like this into the Fedora RPMs, so barring >> objections I'm going to review this, commit it into HEAD, and then >> make a back-ported patch I can use with 8.4 in Fedora. >> > > I find this whole approach a bit evil. If word of this gets out, every > server process on Linux will excuse itself from the OOM killer. And > then the kernel guys will add another setting to override the process > preference. It's an arms race, but maybe that's what's needed. > The trouble is that the OOM heuristics are pretty bad, and many Linux hackers aren't interested in improving them. One of the most prominent told me some years ago "Just turn it off." And the point of this patch is to allow the postmaster to *remove* OOM protection from normal postgres backends. We at least would be playing nice, and not engaging in an arms race. cheers andrew -- 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 9 Jan 2010 17:07 Alex Hunsaker <badalex(a)gmail.com> writes: > On Sat, Jan 9, 2010 at 14:06, Peter Eisentraut <peter_e(a)gmx.net> wrote: >> If word of this gets out, every >> server process on Linux will excuse itself from the OOM killer. And >> then the kernel guys will add another setting to override the process >> preference. > ... maybe it will convince them its time to fix the damn thing. > Although postgres really is kind of special in this regard. Yeah. If they had saner handling of shared-memory accounting, maybe there wouldn't be a need for us to kluge around the OOM logic. 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: Tom Lane on 11 Jan 2010 13:43
Alex Hunsaker <badalex(a)gmail.com> writes: > On Fri, Jan 8, 2010 at 07:27, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> Then, somebody who wants the feature would build with, say, >> -DLINUX_OOM_ADJ=0 >> or another value if they want that. > Here is a stab at that. Applied with some editorialization. I concluded that it'd be better to put the oom_adj reset right into fork_process, rather than scattering the support across several different files. The latter seems vulnerable to errors of omission in future versions, and there's no really strong reason to not have all the child processes behave the same. Also, a single-file patch is a lot easier for packagers to borrow and apply to existing releases, should they choose to. (Already done and tested in Fedora packages ...) 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 |