Skip site navigation (1) Skip section navigation (2)

Re: Setting oom_adj on linux?

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alex Hunsaker <badalex(at)gmail(dot)com>,Magnus Hagander <magnus(at)hagander(dot)net>,Alvaro Herrera <alvherre(at)commandprompt(dot)com>,Andrew Dunstan <andrew(at)dunslane(dot)net>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Setting oom_adj on linux?
Date: 2010-01-08 22:24:06
Message-ID: 20100108222406.GW17756@tamriel.snowman.net (view raw or flat)
Thread:
Lists: pgsql-hackers
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Alex Hunsaker <badalex(at)gmail(dot)com> 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 reads as zero for both the parent daemon
> and its children.  Kinda scary to realize the OOM killer could easily
> lock me out of boxes I run headless.

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:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=473573

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

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.

	Thanks,

		Stephen

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-01-08 22:38:22
Subject: Re: Setting oom_adj on linux?
Previous:From: Guillaume LelargeDate: 2010-01-08 22:22:34
Subject: Re: Application name patch - v3

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group