Alex Hunsaker writes:
> On Fri, Jan 8, 2010 at 07:27, Tom Lane 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 bet
Alex Hunsaker writes:
> On Sat, Jan 9, 2010 at 14:06, Peter Eisentraut 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 co
Peter Eisentraut wrote:
On fre, 2010-01-08 at 11:37 -0500, Tom Lane wrote:
Alex Hunsaker writes:
On Fri, Jan 8, 2010 at 07:27, Tom Lane wrote:
Then, somebody who wants the feature would build with, say,
-DLINUX_OOM_ADJ=0
or another value if they want that.
H
On Sat, Jan 9, 2010 at 14:06, Peter Eisentraut 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 thi
On fre, 2010-01-08 at 11:37 -0500, Tom Lane wrote:
> Alex Hunsaker writes:
> > On Fri, Jan 8, 2010 at 07:27, Tom Lane 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.
>
>
Alex Hunsaker 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
On Fri, Jan 8, 2010 at 15:24, Stephen Frost 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/bugrep
Stephen Frost 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 som
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Alex Hunsaker writes:
> > Sure this was openssh? I just looked through the entire cvs history
> > for opensshp and found 0 references to 'oom' let alone 'oom_adj'.
> > Maybe something distro specific?
>
> FWIW, I see no evidence that sshd on Fedora does an
On Fri, Jan 8, 2010 at 12:45, Tom Lane wrote:
> Alex Hunsaker writes:
>> Sure this was openssh? I just looked through the entire cvs history
>> for opensshp and found 0 references to 'oom' let alone 'oom_adj'.
>> Maybe something distro specific?
>
> FWIW, I see no evidence that sshd on Fedora doe
Alex Hunsaker writes:
> Sure this was openssh? I just looked through the entire cvs history
> for opensshp and found 0 references to 'oom' let alone 'oom_adj'.
> Maybe something distro specific?
FWIW, I see no evidence that sshd on Fedora does anything to change its
oom score --- the oom_adj file
On Fri, Jan 8, 2010 at 10:24, Stephen Frost wrote:
> 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 e
Robert Haas writes:
> 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.
The number of users who will want to do that might be different fro
Stephen Frost writes:
> * Tom Lane (t...@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 inte
On Fri, Jan 8, 2010 at 12:24 PM, Tom Lane wrote:
> Stephen Frost writes:
>> * Tom Lane (t...@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 horribl
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,
Alex,
* Alex Hunsaker (bada...@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
Stephen Frost writes:
> * Tom Lane (t...@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 package
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Alex Hunsaker writes:
> > On Fri, Jan 8, 2010 at 07:27, Tom Lane 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
On Fri, Jan 8, 2010 at 10:07, Stephen Frost wrote:
> * Tom Lane (t...@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 bes
* Tom Lane (t...@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
obvio
* Magnus Hagander (mag...@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 possi
Tom Lane wrote:
> Alex Hunsaker writes:
> > On Fri, Jan 8, 2010 at 07:27, Tom Lane 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 th
Alex Hunsaker writes:
> On Fri, Jan 8, 2010 at 07:27, Tom Lane 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 o
On Fri, Jan 8, 2010 at 07:27, Tom Lane 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.
It sets oom_adj for:
autovacuum workers
archivers (pgarch.c)
regular backends
Also it updates t
On Fri, Jan 8, 2010 at 07:53, Bruce Momjian wrote:
> Alex Hunsaker wrote:
>> On Thu, Jan 7, 2010 at 20:26, Tom Lane wrote:
>> > Alex Hunsaker writes:
> The usual solution for this kind of thing is:
>
> #ifdef LINUX
> #define OOM_ADJUST oom_adjust()
> #else
> #define
Alex Hunsaker wrote:
> On Thu, Jan 7, 2010 at 20:26, Tom Lane wrote:
> > Alex Hunsaker writes:
>
> > We can either drop this in core (with a lot of #ifdef LINUX added)
>
> Any thoughts on doing something like (in fork_process.c)
>
> #ifdef LINUX
> void oom_adjust()
> {
> ...
> }
> #else
> void
Magnus Hagander writes:
> 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 sys
On Fri, Jan 8, 2010 at 04:46, Alex Hunsaker wrote:
> On Thu, Jan 7, 2010 at 20:26, Tom Lane wrote:
>> Alex Hunsaker writes:
>
>> We can either drop this in core (with a lot of #ifdef LINUX added)
>
> Any thoughts on doing something like (in fork_process.c)
>
> #ifdef LINUX
> void oom_adjust()
>
On Thu, Jan 7, 2010 at 20:26, Tom Lane wrote:
> Alex Hunsaker writes:
> We can either drop this in core (with a lot of #ifdef LINUX added)
Any thoughts on doing something like (in fork_process.c)
#ifdef LINUX
void oom_adjust()
{
...
}
#else
void oom_adjust() {}
#endif
So there is only one #if
Alex Hunsaker writes:
> FWIW here is the patch I run. Stupid as the patch may be, count it as
> a +1 for people in the field doing this. Hence a reason to think
> about doing something in core. maybe.
Thanks for the patch --- it's certainly a fine starting point.
We can either drop this in co
On Mon, Jan 4, 2010 at 09:55, Alvaro Herrera wrote:
> 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 soun
Tom Lane wrote:
> Magnus Hagander writes:
>> ...oom_adj...
>
> One interesting thing I read there is:
> Swapped out tasks are killed first. Half of each child's memory size is
> added to the parent's score if they do not share the same memory.
> ^^^
Tom Lane wrote:
> This suggests that PG's shared memory ought not be counted in the
> postmaster's OOM score, which would mean that the problem
> shouldn't be quite as bad as we've believed. I wonder if that is
> a recent change? Or maybe it's supposed to be that way and is not
> implemented c
Magnus Hagander writes:
> I realize this is a very platform-specific thing, but should we
> consider setting the value of /proc//oom_adj when running on
> linux? See:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/proc.txt;h=220cc6376ef80e0c9b
Magnus Hagander wrote:
> On Mon, Jan 4, 2010 at 17:55, Alvaro Herrera
> wrote:
> > BTW, is it possible for pg_ctl to disable OOM-killer? I guess not,
> > since it's not run by root ...
>
> No, it has to run as root.
We could at least make it work on Windows, since it is often run as
Administr
Alvaro Herrera writes:
> Is there a way to disable memory overcommit for particular processes?
I would think not --- the very essence of overcommit is that you're
promising more total memory than the system has got, and that's
inherently a global proposition.
regards, tom
On Mon, Jan 4, 2010 at 17:55, Alvaro Herrera wrote:
> 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 soun
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 p
Greg Smith 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 questione
On Mon, Jan 4, 2010 at 17:40, Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
>>
>> On Mon, Jan 4, 2010 at 17:07, Andrew Dunstan wrote:
>>
>>>
>>> Magnus Hagander wrote:
>>>
On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera
wrote:
>
> Magnus Hagander wrote:
>>
Magnus Hagander wrote:
On Mon, Jan 4, 2010 at 17:07, Andrew Dunstan wrote:
Magnus Hagander wrote:
On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera
wrote:
Magnus Hagander wrote:
I realize this is a very platform-specific thing, but should we
consider setting the value
Magnus Hagander wrote:
On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera wrote:
Magnus Hagander wrote:
I realize this is a very platform-specific thing, but should we
consider setting the value of /proc//oom_adj when running on
linux? See:
http://archives.postgresql.org/message-id/2
On Mon, Jan 4, 2010 at 17:07, Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
>>
>> On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera
>> wrote:
>>
>>>
>>> Magnus Hagander wrote:
>>>
I realize this is a very platform-specific thing, but should we
consider setting the value of /proc//o
Magnus Hagander wrote:
On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera wrote:
Magnus Hagander wrote:
I realize this is a very platform-specific thing, but should we
consider setting the value of /proc//oom_adj when running on
linux? See:
http://archives.postgresql.org/message-id
On Mon, 4 Jan 2010 16:57:28 +0100, Magnus Hagander
wrote:
> On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera
> wrote:
>> Magnus Hagander wrote:
>>> I realize this is a very platform-specific thing, but should we
>>> consider setting the value of /proc//oom_adj when running on
>>> linux? See:
>>
>>
ht
On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera wrote:
> Magnus Hagander wrote:
>> I realize this is a very platform-specific thing, but should we
>> consider setting the value of /proc//oom_adj when running on
>> linux? See:
>
> http://archives.postgresql.org/message-id/20080201223336.GC24780%40alvh
Magnus Hagander wrote:
> I realize this is a very platform-specific thing, but should we
> consider setting the value of /proc//oom_adj when running on
> linux? See:
http://archives.postgresql.org/message-id/20080201223336.GC24780%40alvh.no-ip.org
--
Alvaro Herrera
I realize this is a very platform-specific thing, but should we
consider setting the value of /proc//oom_adj when running on
linux? See:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/proc.txt;h=220cc6376ef80e0c9bcfec162d45552e729cdf5a;hb=45d28b
49 matches
Mail list logo
