On Mon, Sep 30, 2013 at 5:28 PM, Bernd Helmle <mailings@oopsware.de> wrote:
>
>
> --On 30. September 2013 19:00:06 +0200 Andres Freund
> <andres@2ndquadrant.com> wrote:
>
>>> HEAD (default):
>>>
>>> tps = 181738.607247 (including connections establishing)
>>> tps = 182665.993063 (excluding connections establishing)
>>>
>>> HEAD (padding + 16 partitions + your lwlocks patch applied):
>>>
>>> tps = 269328.259833 (including connections establishing)
>>> tps = 270685.666091 (excluding connections establishing)
>>>
>>> So, still an improvement but far away from what you got. Do you have some
>>> other tweaks in your setup?
>>
>>
>> The only relevant setting changed was -c shared_buffers=1GB, no other
>> patches applied. At which scale did you pgbench -i?
>
>
> I've used a scale factor of 10 (i recall you've mentioned using the same
> upthread...).
>
> Okay, i've used 2GB shared buffers, repeating with your setting i get a far
> more noticable speedup:
If Andres's patch passes muster it may end up causing us to
re-evaluate practices for the shared buffer setting. I was trying to
optimize buffer locking in the clock sweep using a different approach
and gave up after not being able to find useful test cases to
demonstrate an improvement. The main reason for this is that clock
sweep issues are masked by contention in the buffer mapping lwlocks
(as you guys noted). I *do* think clock sweep contention comes out in
some production workloads but so far have been elusive to produce in
synthetic testing. Ditto buffer pin contention (this has been
documented).
So I'm very excited about this patch. Right now in servers I
configure (even some very large ones) I set shared buffers to max 2gb
for various reasons. Something tells me that's about to change.
merlin
