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: Tom Lane on 8 Jan 2010 12:24 Stephen Frost <sfrost(a)snowman.net> writes: > * 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. I'm a packager, and I think that this approach is perfectly fine. The place where the rubber meets the road is in the init script, which is the packager's responsibility. If the packager is going to provide an init script that sets oom_adj in the first place, he can turn on the compensation code inside the binary. If not, the compensation code has no purpose anyhow. There are no moving parts in this as far as the end user is concerned. > 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, We just ignore any error from the attempt to write to /proc. > 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, I think you are missing the point that the code won't even be compiled except on platforms where the packager has determined that it's sensible to have it. 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: Stephen Frost on 8 Jan 2010 12:24 Alex, * Alex Hunsaker (badalex(a)gmail.com) wrote: > 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). As I recall, oom_adj wasn't visible in the container because you explicitly set what proc entries processes can have access to when using VServers, and OpenSSH didn't handle that cleanly. Guess what I'm just saying is "don't just assume everything is as it would be on a 'normal' system when dealing with /proc and friends", and, of course, test, test, test when you're talking about back-porting things. Thanks, Stephen
From: Andrew Dunstan on 8 Jan 2010 12:34 Tom Lane wrote: > I don't want to go to the trouble of creating (and documenting) a > configure option for this. Much less a GUC ;-) > > What I suggest is that we do something like > > #ifdef LINUX_OOM_ADJ > ... > fprintf(oom, "%d\n", LINUX_OOM_ADJ); > ... > #endif > > Then, somebody who wants the feature would build with, say, > -DLINUX_OOM_ADJ=0 > or another value if they want that. > > +1 for this. Looks like a sound approach. 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: Robert Haas on 8 Jan 2010 12:37 On Fri, Jan 8, 2010 at 12:24 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Stephen Frost <sfrost(a)snowman.net> writes: >> * 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. > > I'm a packager, and I think that this approach is perfectly fine. > The place where the rubber meets the road is in the init script, > which is the packager's responsibility. If the packager is going > to provide an init script that sets oom_adj in the first place, > he can turn on the compensation code inside the binary. If not, > the compensation code has no purpose anyhow. There are no moving > parts in this as far as the end user is concerned. There could well be moving parts if the user wants to adjust the value being written to oom_adj, and can't because it's compiled in. I don't see why we can't just add a GUC for this and be done with it. ....Robert -- 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 8 Jan 2010 12:45
Stephen Frost <sfrost(a)snowman.net> writes: > * 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. BTW, maybe you're confused about the intention here? You'd need a custom build to *enable* it, not to disable it. 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 |