The never ending quest for clarity on shared_buffers

From: Doug Y <dylists(at)ptd(dot)net>
To: pgsql-performance(at)postgresql(dot)org
Subject: The never ending quest for clarity on shared_buffers
Date: 2004-10-06 20:04:52
Message-ID: 6.1.2.0.2.20041006152747.033bcd50@pop.traderonline.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Hello,
We recently upgraded os from rh 7.2 (2.4 kernel) to Suse 9.1 (2.6
kernel), and psql from 7.3.4 to 7.4.2

One of the quirks I've noticed is how the queries don't always have the
same explain plans on the new psql... but that's a different email I think.

My main question is I'm trying to convince the powers that be to let me
use persistent DB connections (from apache 2 / php), and my research has
yielded conflicting documentation about the shared_buffers setting... real
shocker there :)

For idle persistent connections, do each of them allocate the memory
specified by this setting (shared_buffers * 8k), or is it one pool used by
all the connection (which seems the logical conclusion based on the name
SHARED_buffers)? Personally I'm more inclined to think the latter choice,
but I've seen references that alluded to both cases, but never a definitive
answer.

For what its worth, shared_buffers is currently set to 50000 (on a 4G
system). Also, effective_cache_size is 125000. max_connections is 256, so I
don't want to end up with a possible 100G (50k * 8k * 256) of memory tied
up... not that it would be possible, but you never know.

I typically never see more than a dozen or so concurrent connections to
the db (serving 3 web servers), so I'm thinking of actually using something
like pgpool to keep about 10 per web server, rather than use traditional
persistent connections of 1 per Apache child, which would probably average
about 50 per web server.

Thanks.

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2004-10-06 20:20:03 Re: sequential scan on select distinct
Previous Message Greg Stark 2004-10-06 20:02:22 Re: sequential scan on select distinct