Re: heavily contended lwlocks with long wait queues scale badly - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: heavily contended lwlocks with long wait queues scale badly
Date
Msg-id CAFiTN-vYVRj=EPV3S=8LB76xTqx7i0kc9B98=oJr2xXVbmDQfw@mail.gmail.com
Whole thread Raw
In response to Re: heavily contended lwlocks with long wait queues scale badly  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
On Mon, Oct 31, 2022 at 11:03 AM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
>
> At Thu, 27 Oct 2022 09:59:14 -0700, Andres Freund <andres@anarazel.de> wrote in
> > But I think we can solve that fairly reasonably nonetheless. We can change
> > PGPROC->lwWaiting to not just be a boolean, but have three states:
> > 0: not waiting
> > 1: waiting in waitlist
> > 2: waiting to be woken up
> >
> > which we then can use in LWLockDequeueSelf() to only remove ourselves from the
> > list if we're on it. As removal from that list is protected by the wait list
> > lock, there's no race to worry about.

This looks like a good idea.


> No. It enlarges PRPC by 8 bytes, but changing lwWaiting to int8/uint8
> keeps the size as it is. (Rocky8/x86-64)

I agree

> It just shaves off looping cycles. So +1 for what the patch does.
>
>
> > client  patched   HEAD
> > 1        60109    60174
> > 2       112694   116169
> > 4       214287   208119
> > 8       377459   373685
> > 16      524132   515247
> > 32      565772   554726
> > 64      587716   497508
> > 128     581297   415097
> > 256     550296   334923
> > 512     486207   243679
> > 768     449673   192959
> > 1024    410836   157734
> > 2048    326224    82904
> > 4096    250252    32007
> >
> > Not perfect with the patch, but not awful either.
>
> Fairly good? Agreed.  The performance peak is improved by 6% and
> shifted to larger number of clients (32->128).
>

The performance result is promising so +1

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Check return value of pclose() correctly
Next
From: Peter Eisentraut
Date:
Subject: Re: Expand palloc/pg_malloc API