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

Re: First set of OSDL Shared Mem scalability results, some

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: Christopher Browne <cbbrowne(at)acm(dot)org>,pgsql-performance(at)postgresql(dot)org
Subject: Re: First set of OSDL Shared Mem scalability results, some
Date: 2004-10-14 03:52:27
Message-ID: 871xg25538.fsf@stark.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:

> On 10/8/2004 10:10 PM, Christopher Browne wrote:
> 
> > josh(at)agliodbs(dot)com (Josh Berkus) wrote:
> >> I've been trying to peg the "sweet spot" for shared memory using
> >> OSDL's equipment.  With Jan's new ARC patch, I was expecting that
> >> the desired amount of shared_buffers to be greatly increased.  This
> >> has not turned out to be the case.
> > That doesn't surprise me.
> 
> Neither does it surprise me.

There's been some speculation that having a large shared buffers be about 50%
of your RAM is pessimal as it guarantees the OS cache is merely doubling up on
all the buffers postgres is keeping. I wonder whether there's a second sweet
spot where the postgres cache is closer to the total amount of RAM.

That configuration would have disadvantages for servers running other jobs
besides postgres. And I was led to believe earlier that postgres starts each
backend with a fairly fresh slate as far as the ARC algorithm, so it wouldn't
work well for a postgres server that had lots of short to moderate life
sessions.

But if it were even close it could be interesting. Reading the data with
O_DIRECT and having a single global cache could be interesting experiments. I
know there are arguments against each of these, but ...

I'm still pulling for an mmap approach to eliminate postgres's buffer cache
entirely in the long term, but it seems like slim odds now. But one way or the
other having two layers of buffering seems like a waste.

-- 
greg


In response to

Responses

pgsql-performance by date

Next:From: Jan WieckDate: 2004-10-14 04:17:34
Subject: Re: First set of OSDL Shared Mem scalability results, some
Previous:From: Bruce MomjianDate: 2004-10-14 03:47:05
Subject: Re: Free PostgreSQL Training, Philadelphia, Oct 30

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-10-14 03:55:10
Subject: Re: [COMMITTERS] pgsql: Fix breakage in hashjoin from recent
Previous:From: Oliver JowettDate: 2004-10-14 03:14:06
Subject: Re: Two-phase commit security restrictions

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