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

From Decibel!
Subject Re: configurability of OOM killer
Date
Msg-id 20080206013948.GL1212@decibel.org
Whole thread Raw
In response to Re: configurability of OOM killer  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
List pgsql-hackers
On Tue, Feb 05, 2008 at 01:54:17PM -0800, Ron Mayer wrote:
> Decibel! wrote:
> >
> > Yes, this problem goes way beyond OOM. Just try and configure
> > work_memory aggressively on a server that might see 50 database
> > connections, and do it in such a way that you won't swap. Good luck.
>
> That sounds like an even broader and more difficult problem
> than managing memory.
>
> If you have 50 connections that all want to perform large sorts,
> what do you want to have happen?
>
>   a) they each do their sorts in parallel with small amounts
>      of memory for each; probably all spilling to disk?
>   b) they each get a big chunk of memory but some have to
>      wait for each other?
>   c) something else?
>
> Seems (a)'s already possible today with setting small work_mem.
> Seems (b)'s already possible today with a larger work_mem and
> pg_pool.

b is not possible with pgpool; you're assuming that all connections are
trying to use work_mem.

> Stepping back from the technical details, what do you think
> should happen.   (though perhaps it should be taken to a different
> thread)

Yes... it's been discussed in the past. As Simon said, the first step is
deciding that this is a problem, then we can try and figure out a
solution.
--
Decibel!, aka Jim C. Nasby, Database Architect  decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: GSSAPI and V2 protocol
Next
From: Tom Lane
Date:
Subject: Re: GSSAPI and V2 protocol