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 17:38 Stephen Frost <sfrost(a)snowman.net> writes: > The other issue was with a Debian-specific patch which was applied to > OpenSSH which basically just created noise in the log file, bug report > here: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487325 Hmm, that's pretty interesting, specifically this: : After some discussion with the Linux-Vserver folks, they found some : interesting information I thought it worth adding. First EPERM is not : the error that they expected, and that inside a vserver guest its really : strict about what options you open it with, both O_CREAT and O_TRUNC are : forbidden, and O_WRONLY lets you write 0\n to it. That suggests it might be worth our trouble to use open/write rather than fopen, so that we can ensure the flags are correct to avoid this type of restriction. But in any case the main takeaway seems to be to not insist on the operation succeeding ;-) 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: Alex Hunsaker on 8 Jan 2010 22:46 On Fri, Jan 8, 2010 at 15:24, Stephen Frost <sfrost(a)snowman.net> wrote: > There were a few issues, as it turns out, the particularly annoying one > was in the init script which caused upgrades to fail due to sshd not > being restarted, bug report here: Thanks for the pointers! > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=473573 The changes I proposed to the example linux startup script wont suffer from that. > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487325 > > In the end, the problem was with errors being returned from attempts to > modify oom_adj. Â As long as we can just ignore those hopefully there > won't be any issues. Yep sounds good. Thanks again! Tom, sounds like you got busy with other stuff :) Should I submit a new patch that uses open and O_WRONLY? -- 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 22:57 Alex Hunsaker <badalex(a)gmail.com> writes: > Tom, sounds like you got busy with other stuff :) Should I submit a > new patch that uses open and O_WRONLY? No, I was just waiting to see if there were more comments. I can take it from here. 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: Peter Eisentraut on 9 Jan 2010 16:06 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. -- 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: Alex Hunsaker on 9 Jan 2010 16:53
On Sat, Jan 9, 2010 at 14:06, Peter Eisentraut <peter_e(a)gmx.net> wrote: > I find this whole approach a bit evil. I would tend to agree but this type of thing has been known since about 2004... See http://thoughts.j-davis.com/2009/11/29/linux-oom-killer/, particularly the comment from Greg Smith. > 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. Yes, and note debian is already doing that with things like ssh. Who knows what else. (Id be curious to know) Plus maybe it will convince them its time to fix the damn thing. Although postgres really is kind of special in this regard. All the other daemons on my system include X had way lower oom scores. Alsamixer was 3 times more likely to get killed than the first daemon with the highest score (hald) while postgres was 55 times more likely. Yes its the kernel being stupid, but its been known for more than 6 years... (oom scores: alsamxier: 1497, hald: 487, postgres: 26558) > It's an arms race, but maybe that's what's needed. Well *shrug* regardless of what core does... Ill certainly be doing it on my postgres linux builds :) Maybe it would convince them more if we could get distros to accept patches that fix the kernel to do correct/better shared mem accounting? May I add good luck? :) -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |