Jim Nasby wrote:
I've also seen large shared buffer settings perform poorly outside of IO
issues, presumably due to some kind of internal lock contention. I tried
running 8.3 with 24G for a while, but dropped it back down to our default of 8G
after noticing some performance problems. Unfortunately I don't remember the
exact details, let alone having a repeatable test case
We got a report for Jignesh at Sun once that he had a benchmark workload
where there was a clear performance wall at around 10GB of
shared_buffers. At
http://blogs.sun.com/jkshah/entry/postgresql_east_2008_talk_best he says:
"Shared Bufferpool getting better in 8.2, worth to increase it to 3GB
(for 32-bit PostgreSQL) but still
not great to increase it more than 10GB (for 64-bit PostgreSQL)"
So you running into the same wall around the same amount just fuels the
existing idea there's an underlying scalablity issue in there. Nobody
with that right hardware has put it under the light of a profiler yet as
far as I know.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
g...@2ndquadrant.com www.2ndQuadrant.us
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
