Jim Nasby wrote:
> I've also seen large shared buffer settings perform poorly outside of IO issues, presumably due to some kind of
internallock contention. I tried running 8.3 with 24G for a while, but dropped it back down to our default of 8G after
noticingsome 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
greg@2ndQuadrant.com www.2ndQuadrant.us
