On Wed, Apr 21, 2010 at 2:54 AM, Greg Smith <greg@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
