Re: Speed up Clog Access by increasing CLOG buffers

On Wed, Sep 21, 2016 at 3:48 AM, Tomas Vondra
<tomas.vondra@2ndquadrant.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