At 12:36 AM -0400 9/25/09, Tom Lane wrote:
Dan Sugalski <> writes:
Is there any practical limit to the number of shared buffers PG 8.3.7
can handle before more becomes counter-productive?
Probably, but I've not heard any definitive measurements showing an
upper limit. The traditional wisdom of limiting it to 1G or so dates
from before the last rounds of revisions to the bufmgr logic.
My production DB's around 200G, and the box hosting it has 192G of
memory on it, running a 64 bit AIX build of 8.3.7.
Yowza. You might be able to do measurements that no one has done
before. Let us know what you find out.
:) It's a machine of non-trivial size, to be sure. I'll give the
buffer setting a good bump and see how it goes. I may be able to take
one of the slony replicas off-line the next holiday and run some
performance tests, but that won't be for a while.
BTW, does AIX have any provision for locking shared memory into RAM?
One of the gotchas for large shared memory has always been the risk
that the kernel would decide to swap some of it out.
I'll have to go check, but I think it does. This box hasn't actually
hit swap since it started -- a good chunk of that RAM is used as
semi-permanent disk cache but unfortunately the regular day-to-day
use of this box (they won't let me have it as a dedicated DB-only
machine. Go figure :) doing other stuff the cache tends to turn over
pretty quickly.

--------------------------------------it's like this-------------------
Dan Sugalski even samurai have teddy bears and even
teddy bears get drunk

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 16 | next ›
Discussion Overview
grouppgsql-performance @
postedSep 25, '09 at 3:28a
activeSep 28, '09 at 6:00p



site design / logo © 2019 Grokbase