On Wed, Apr 21, 2010 at 2:54 AM, Greg Smith <g...@2ndquadrant.com> wrote: > 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.
It might be interesting to see whether increasing NUM_BUFFER_PARTITIONS, LOG2_NUM_LOCK_PARTITIONS, and NUM_LOCK_PARTITIONS alleviates this problem at all. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
