Re: Fix performance degradation of contended LWLock on NUMA

On 2017-07-18 20:20, Sokolov Yura wrote:
> On 2017-06-05 16:22, Sokolov Yura wrote:
>> Good day, everyone.
>>
>> This patch improves performance of contended LWLock.
>> Patch makes lock acquiring in single CAS loop:
>> 1. LWLock->state is read, and ability for lock acquiring is detected.
>> If there is possibility to take a lock, CAS tried.
>> If CAS were successful, lock is aquired (same to original version).
>> 2. but if lock is currently held by other backend, we check ability
>> for
>> taking WaitList lock. If wait list lock is not help by anyone, CAS
>> perfomed for taking WaitList lock and set LW_FLAG_HAS_WAITERS at
>> once.
>> If CAS were successful, then LWLock were still held at the moment
>> wait
>> list lock were held - this proves correctness of new algorithm. And
>> Proc is queued to wait list then.
>> 3. Otherwise spin_delay is performed, and loop returns to step 1.
>>
>
> I'm sending rebased version with couple of one-line tweaks.
> (less skip_wait_list on shared lock, and don't update spin-stat on
> aquiring)
>
> With regards,

Here are results for zipfian distribution (50/50 r/w) in conjunction
with "lazy hash table for XidInMVCCSnapshot":
(https://www.postgresql.org/message-id/642da34694800dab801f04c62950ce8a%40postgrespro.ru)

clients | master | hashsnap2 | hashsnap2_lwlock
--------+--------+-----------+------------------
10 | 203384 | 203813 | 204852
20 | 334344 | 334268 | 363510
40 | 228496 | 231777 | 383820
70 | 146892 | 148173 | 221326
110 | 99741 | 111580 | 157327
160 | 65257 | 81230 | 112028
230 | 38344 | 56790 | 77514
310 | 22355 | 39249 | 55907
400 | 13402 | 26899 | 39742
500 | 8382 | 17855 | 28362
650 | 5313 | 11450 | 17497
800 | 3352 | 7816 | 11030

With regards,
--
Sokolov Yura aka funny_falcon
Postgres Professional: https://postgrespro.ru
The Russian Postgres Company