Re: Speed up Clog Access by increasing CLOG buffers

On Wed, Sep 21, 2016 at 3:48 AM, Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>
> I have no idea what's causing this - it might be related to the kernel, but
> I'm not sure why it should affect the patches differently. Let's see how the
> new kernel affects this.
>
> dilip / sync=off 16 32 64 128 192
> --------------------------------------------------------------
> master 26198 37901 37211 14441 8315
> granular-locking 25829 38395 40626 14299 8160
> no-content-lock 25872 38994 41053 14058 8169
> group-update 26503 38911 42993 19474 8325
>
> dilip / sync=on 16 32 64 128 192
> --------------------------------------------------------------
> master 26138 37790 38492 13653 8337
> granular-locking 25661 38586 40692 14535 8311
> no-content-lock 25653 39059 41169 14370 8373
> group-update 26472 39170 42126 18923 8366
>
> pgbench / sync=off 16 32 64 128 192
> --------------------------------------------------------------
> master 23001 35762 41202 31789 8005
> granular-locking 23218 36130 42535 45850 8701
> no-content-lock 23322 36553 42772 47394 8204
> group-update 23129 36177 41788 46419 8163
>
> pgbench / sync=on 16 32 64 128 192
> --------------------------------------------------------------
> master 22904 36077 41295 35574 8297
> granular-locking 23323 36254 42446 43909 8959
> no-content-lock 23304 36670 42606 48440 8813
> group-update 23127 36696 41859 46693 8345
>
>
> So there is some improvement due to the patches for 128 clients (+30% in
> some cases), but it's rather useless as 64 clients either give you
> comparable performance (pgbench workload) or way better one (Dilip's
> workload).
>

I think these results are somewhat similar to what Dilip has reported.
Here, if you see in both cases, the performance improvement is seen
when the client count is greater than cores (including HT). As far as
I know the m/c on which Dilip is running the tests also has 64 HT.
The point here is that the CLOGControlLock contention is noticeable
only at that client count, so it is not fault of patch that it is not
improving at lower client-count. I guess that we will see performance
improvement between 64~128 client counts as well.

> Also, pretty much no difference between synchronous_commit on/off, probably
> thanks to running on unlogged tables.
>

Yeah.

> I'll repeat the test on the 4-socket machine with a newer kernel, but that's
> probably the last benchmark I'll do for this patch for now.
>

Okay, but I think it is better to see the results between 64~128
client count and may be greater than128 client counts, because it is
clear that patch won't improve performance below that.

> I agree with
> Robert that the cases the patch is supposed to improve are a bit contrived
> because of the very high client counts.
>

No issues, I have already explained why I think it is important to
reduce the remaining CLOGControlLock contention in yesterday's and
this mail. If none of you is convinced, then I think we have no
choice but to drop this patch.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com