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: Bruce Momjian on 8 Jan 2010 11:45 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. Go for it, but FYI, we need to udpate the our OOM documentation mention to reflect this change. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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: Stephen Frost on 8 Jan 2010 12:03 * Magnus Hagander (magnus(a)hagander.net) wrote: > 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. We do need to make it configurable, in at least the sense of being able to control if it's done or not. There are some environments where you won't be able to set it. Perhaps just handling failure gracefully would work, but I'd be happier if you could just disable it in the config file. Thanks, Stephen
From: Stephen Frost on 8 Jan 2010 12:07 * Tom Lane (tgl(a)sss.pgh.pa.us) wrote: > I don't want to go to the trouble of creating (and documenting) a > configure option for this. Much less a GUC ;-) Requiring a custom build to disable it would be horrible, in my view. Or, at best, just means that the packagers won't enable it, which obviously would be less than ideal. Sorry if it's a pain, but I think it needs to either be configurable or not done. As I said before, it definitely needs to handle failure gracefully, but I worry that even that won't be sufficient in some cases. Just thinking about how we run PG under VServers and Linux Containers and whatnot, we ran into some issues with OpenSSH trying to monkey with proc values and I'd really hate to run into the same issues with PG. Thanks, Stephen
From: Alex Hunsaker on 8 Jan 2010 12:11 On Fri, Jan 8, 2010 at 10:07, Stephen Frost <sfrost(a)snowman.net> wrote: > * Tom Lane (tgl(a)sss.pgh.pa.us) wrote: >> I don't want to go to the trouble of creating (and documenting) a >> configure option for this. Â Much less a GUC ;-) > > Requiring a custom build to disable it would be horrible, in my view. > Or, at best, just means that the packagers won't enable it, which > obviously would be less than ideal. FWIW I agree. > Sorry if it's a pain, but I think it needs to either be configurable or > not done. Â As I said before, it definitely needs to handle failure > gracefully, but I worry that even that won't be sufficient in some > cases. Â Just thinking about how we run PG under VServers and Linux > Containers and whatnot, we ran into some issues with OpenSSH trying to > monkey with proc values and I'd really hate to run into the same issues > with PG. As long as the VM/container you are running under wont kill postmaster for trying to access proc-- the patch I posted should work fine. It just ignores any error (I assumed you might be running in a chroot without proc or some such). -- 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: Stephen Frost on 8 Jan 2010 12:12
* Tom Lane (tgl(a)sss.pgh.pa.us) 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. Whoah, I would caution against doing that without being very confident it won't break when installed under things like VServer, Linux Containers, SELinux configurations, etc, when back-porting it. I don't expect people would be too pleased to discover their "nice, simple, no-expected-issues" upgrade of a minor point release to all of a sudden mean their database doesn't start anymore.. Sorry I havn't got time right now to run down the issue I had with OpenSSH doing something similar, and it might have just been poor coding in OpenSSH, but I wanted to voice my concern. Thanks, Stephen |