Prev: [HACKERS] standbycheck was:(Re: [HACKERS] testing hot standby
Next: [BUGS] BUG #5412: test case produced, possible race condition.
From: Robert Haas on 22 Apr 2010 23:10
On Wed, Apr 21, 2010 at 2:54 AM, Greg Smith <greg(a)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(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: [HACKERS] standbycheck was:(Re: [HACKERS] testing hot standby
Next: [BUGS] BUG #5412: test case produced, possible race condition.