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: Greg Smith on 4 Jan 2010 11:17 Magnus Hagander wrote: > On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera <alvherre(a)commandprompt.com> wrote: > >> Magnus Hagander wrote: >> >>> 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://archives.postgresql.org/message-id/20080201223336.GC24780%40alvh.no-ip.org >> > > Can't find a useful consensus though? > In http://archives.postgresql.org/pgsql-hackers/2008-02/msg00049.php Tom points out that while you could make this adjustment in the init scripts for PostgreSQL, actually doing so is quite questionable as a packaging decision. That's where that thread ended as far as I was concerned. The best I think anyone could do here is to add such a capability into some of the init scripts, but it would probably need to be disabled by default. Since that sort of defeats the purpose of the change, I'm not sure what the benefit there is--if you have to turn it on, you might as well do something at a higher level instead. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg(a)2ndQuadrant.com www.2ndQuadrant.com
From: Andrew Dunstan on 4 Jan 2010 11:40 Magnus Hagander wrote: > On Mon, Jan 4, 2010 at 17:07, Andrew Dunstan <andrew(a)dunslane.net> wrote: > >> Magnus Hagander wrote: >> >>> On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera <alvherre(a)commandprompt.com> >>> wrote: >>> >>> >>>> Magnus Hagander wrote: >>>> >>>> >>>>> 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://archives.postgresql.org/message-id/20080201223336.GC24780%40alvh.no-ip.org >>>> >>>> >>> Grr. I had zero recollectoin of that :S >>> >>> Can't find a useful consensus though? >>> >>> >>> >> It is probably worth trying to protect the postmaster in the init script. >> Beyond that things probably start to get fairly difficult. >> > > Right. But AFAICS (though I haven't tested with -17), it will become > inherited to children, which is something we'd want to *undo*, no? > [experiments] Yes, darnit, you're right. But it looks like the oom_adj file can be set to the default by the process owner: [andrew(a)sophia ~]$ ls -l /proc/6520/oom_adj -rw-r--r-- 1 andrew andrew 0 2010-01-04 12:37 /proc/6520/oom_adj [andrew(a)sophia ~]$ cat /proc/6520/oom_adj 0 [andrew(a)sophia ~]$ id uid=500(andrew) gid=500(andrew) groups=10(wheel),500(andrew) [andrew(a)sophia ~]$ echo -17 > /proc/6520/oom_adj -bash: echo: write error: Permission denied [andrew(a)sophia ~]$ echo 0 > /proc/6520/oom_adj [andrew(a)sophia ~]$ echo -17 > /proc/6520/oom_adj -bash: echo: write error: Permission denied [andrew(a)sophia ~]$ But that would be a pain to have to do. OTOH, disabling the OOM killer is not always an option. I recently tried it on one system and had to revert it rapidly because the system stopped working in minutes. Some software just doesn't live well in such environments, sadly. 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: Magnus Hagander on 4 Jan 2010 11:41 On Mon, Jan 4, 2010 at 17:40, Andrew Dunstan <andrew(a)dunslane.net> wrote: > > > Magnus Hagander wrote: >> >> On Mon, Jan 4, 2010 at 17:07, Andrew Dunstan <andrew(a)dunslane.net> wrote: >> >>> >>> Magnus Hagander wrote: >>> >>>> >>>> On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera >>>> <alvherre(a)commandprompt.com> >>>> wrote: >>>> >>>> >>>>> >>>>> Magnus Hagander wrote: >>>>> >>>>> >>>>>> >>>>>> 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://archives.postgresql.org/message-id/20080201223336.GC24780%40alvh.no-ip.org >>>>> >>>>> >>>> >>>> Grr. I had zero recollectoin of that :S >>>> >>>> Can't find a useful consensus though? >>>> >>>> >>>> >>> >>> It is probably worth trying to protect the postmaster in the init script. >>> Beyond that things probably start to get fairly difficult. >>> >> >> Right. But AFAICS (though I haven't tested with -17), it will become >> inherited to children, which is something we'd want to *undo*, no? >> > > > [experiments] > > Yes, darnit, you're right. But it looks like the oom_adj file can be set to > the default by the process owner: > > [andrew(a)sophia ~]$ ls -l /proc/6520/oom_adj > -rw-r--r-- 1 andrew andrew 0 2010-01-04 12:37 /proc/6520/oom_adj > [andrew(a)sophia ~]$ cat /proc/6520/oom_adj > 0 > [andrew(a)sophia ~]$ id > uid=500(andrew) gid=500(andrew) groups=10(wheel),500(andrew) > [andrew(a)sophia ~]$ echo -17 > /proc/6520/oom_adj > -bash: echo: write error: Permission denied > [andrew(a)sophia ~]$ echo 0 > /proc/6520/oom_adj > [andrew(a)sophia ~]$ echo -17 > /proc/6520/oom_adj > -bash: echo: write error: Permission denied > [andrew(a)sophia ~]$ > > But that would be a pain to have to do. > > OTOH, disabling the OOM killer is not always an option. I recently tried it > on one system and had to revert it rapidly because the system stopped > working in minutes. Some software just doesn't live well in such > environments, sadly. 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. -- 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 4 Jan 2010 11:49 Greg Smith <greg(a)2ndquadrant.com> writes: > In http://archives.postgresql.org/pgsql-hackers/2008-02/msg00049.php Tom > points out that while you could make this adjustment in the init scripts > for PostgreSQL, actually doing so is quite questionable as a packaging > decision. I just wondered if it would be questioned, I didn't say there was a problem. However, the long and the short of this is that we can't do anything without the close cooperation of an init script. I think that moves it out of the realm of what Postgres as a project should be doing. It seems more like a patch that the Linux-based packagers should be carrying. Memo to self: get off duff and prepare such a patch for the Red Hat/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
From: Alvaro Herrera on 4 Jan 2010 11:55
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. BTW, is it possible for pg_ctl to disable OOM-killer? I guess not, since it's not run by 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. -- 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 |