Re: heavily contended lwlocks with long wait queues scale badly

On Mon, Oct 31, 2022 at 11:03 AM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:
>
> At Thu, 27 Oct 2022 09:59:14 -0700, Andres Freund <andres(at)anarazel(dot)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