From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | Jim Nasby <decibel(at)decibel(dot)org>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: shared_buffers documentation |
Date: | 2010-04-23 03:10:25 |
Message-ID: | q2v603c8f071004222010m7603fbeaga5d622764cc3a5bd@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 21, 2010 at 2:54 AM, Greg Smith <greg(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-04-23 04:46:35 | Re: why do we have rd_istemp? |
Previous Message | Erik Rijkers | 2010-04-23 01:08:50 | Re: Assertion failure twophase.c (3) (testing HS/SR) |