Re: configurability of OOM killer - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: configurability of OOM killer
Date
Msg-id 1202155608.4252.570.camel@ebony.site
Whole thread Raw
In response to Re: configurability of OOM killer  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: configurability of OOM killer
Re: configurability of OOM killer
List pgsql-hackers
On Mon, 2008-02-04 at 11:38 -0800, Jeff Davis wrote:
> On Mon, 2008-02-04 at 19:29 +0000, Simon Riggs wrote:
> > On Mon, 2008-02-04 at 10:57 -0800, Jeff Davis wrote:
> > 
> > > I tried bringing this up on LKML several times (Ron Mayer linked to one
> > > of my posts: http://lkml.org/lkml/2007/2/9/275). If anyone has an inside
> > > connection to the linux developer community, I suggest that they raise
> > > this issue.
> > > 
> > > If you want to experiment, start a postgres process with shared_buffers
> > > set at 25% of the available memory, and then start about 100 idle
> > > connections. Then, start a process that just slowly eats memory, such
> > > that it will invoke the OOM killer after a couple minutes (badness()
> > > takes into account the time the process has been alive, as well, so you
> > > can't just eat memory in a tight loop).
> > > 
> > > The postgres process will always be killed, and then it will realize
> > > that it didn't alleviate the memory pressure much, and then kill the
> > > runaway process.
> > 
> > I think the badness() thing sucks badly too, but if we don't keep our
> > own house in order then they're not going to listen.
> 
> I am missing something, can you elaborate? What is postgresql doing
> wrong?

We make no attempt to limit our overall memory usage. We limit
individual sessions by default, but don't prevent them from increasing
that allocation as they choose. We don't try to reallocate memory once
it has finished being used.

This isn't criticism; we are where we are. I just want to gain agreement
that we should be looking at that as a high priority for the next
release.

--  Simon Riggs 2ndQuadrant  http://www.2ndQuadrant.com 



pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Page-at-a-time Locking Considerations
Next
From: Tom Lane
Date:
Subject: Re: configurability of OOM killer