Re: Move PinBuffer and UnpinBuffer to atomics

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Re: Move PinBuffer and UnpinBuffer to atomics
Дата
Msg-id CAPpHfduwFXv_nrCcCP1PX-j=kEmJXc_GTHKULmQT3xCneoNyFg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Move PinBuffer and UnpinBuffer to atomics  (Dilip Kumar <dilipbalaut@gmail.com>)
Ответы Re: Move PinBuffer and UnpinBuffer to atomics  (Dilip Kumar <dilipbalaut@gmail.com>)
Список pgsql-hackers
Дерево обсуждения
On Sat, Mar 19, 2016 at 3:22 PM, Dilip Kumar <dilipbalaut@gmail.com> wrote:

On Mon, Mar 14, 2016 at 3:09 AM, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote:
I've drawn graphs for these measurements. The variation doesn't look random here.  TPS is going higher from measurement to measurement.  I bet you did measurements sequentially.
I think we should do more measurements until TPS stop growing and beyond to see accumulate average statistics.  Could you please do the same tests but 50 runs.

I have taken reading at different client count (1,2 and 4)

1. Avg: Is taken average after discarding lowest 5 and highest 5 readings.
2. With 4 client I have only 30 reading.

Summary:

I think if we check avg or median atleast at 1 or 2 client head always looks winner, but same is not the case with 4 clients. And with 4 clients I can see much more fluctuation in the reading.


Head(1 Client)Patch (1 Client)
Head (2 Client)Patch (2 Client)
Head (4 Client)Patch (4 Client)
Avg:1962819578
3718036536
7004470731
Median:1966319581
3796737484
7300375376

Below is all the reading. (Arranged in sorted order)

RunsHead (1 Client)Patch (1 Client)
Head (2 Client)Patch (2 Client)
Head (4 Client)Patch (4 Client)
11819118153
2945426128
4993147210
21836518768
3121826956
5335847287
31905318769
3180829286
5357555458
41912818915
3186030558
5428255794
51916018948
3241130945
5662956253
61917719055
3245331316
5759558147
71935119232
3257131703
5949058543
81935319239
3329432029
6388758990
91936119255
3393632217
6471860233
101939019297
3436132767
6573768210
111945219368
3456334487
6588171409
121947819387
3611034907
6715172108
131948819388
3622134936
7097473977
141949019395
3646135068
7221274891
151951219406
3671235298
7300375376
161953819450
3710435492
7484275468
171954719487
3724636648
7540075515
181959219521
3756737263
7557375626
191962719536
3770737430
7579875745
201966119556
3795837461
7583475868
211966619607
3797637507
7624076161
221970119624
3806037557
7642676162
231970819643
3824437717
7677076333
241974819684
3827238285
7701177009
251975119694
3846738294
7711477168
261977619695
3852438469
7763077318
271978119709
3862538642
7786577550
281978619765
3875638643
7791277904
291979619823
3893938649
7824278736
301982619847
3913938659


311983719899
3920838713


321984919909
3921138837


331985419932
3923038876


341986719949
3924939088


351989119990
3925939148


362003820085
3928639453


372008320128
3943539563


382014320166
3944839959


392019120198
3947540495


402043720455
4037540664



So, I think it's really some regression here on small number clients.  I have following hypothesis about that.  In some cases we use more atomic operations than before. For instace, in BufferAlloc we have following block of code.  Previous code deals with that without atomic operations relying on spinlock.  So, we have 2 extra atomic operations here, and similar situation in other places.

    pg_atomic_fetch_and_u32(&buf->state, ~(BM_VALID | BM_DIRTY | BM_JUST_DIRTIED | BM_CHECKPOINT_NEEDED | BM_IO_ERROR | BM_PERMANENT | BUF_USAGECOUNT_MASK)); if (relpersistence == RELPERSISTENCE_PERMANENT) pg_atomic_fetch_or_u32(&buf->state, BM_TAG_VALID | BM_PERMANENT | BUF_USAGECOUNT_ONE); else pg_atomic_fetch_or_u32(&buf->state, BM_TAG_VALID | BUF_USAGECOUNT_ONE);
Actually, we behave like old code and do such modifications without increasing number of atomic operations.  We can just calculate new value of state (including unset of BM_LOCKED flag) and write it to the buffer.  In this case we don't require more atomic operations.  However, it becomes not safe to use atomic decrement in UnpinBuffer().  We can use there loop of CAS which wait buffer header to be unlocked like PinBuffer() does.  I'm not sure if this affects multicore scalability, but I think it worth trying.

So, this idea is implemented in attached patch.  Please, try it for both regression on lower number of clients and scalability on large number of clients.

Other changes in this patch:
1) PinBuffer() and UnpinBuffer() use exponential backoff in spindealy like LockBufHdr() does.
2) Previous patch contained revert of ac1d7945f866b1928c2554c0f80fd52d7f977772.  This was not intentional.  No, it doesn't contains this revert.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: incorrect docs for pgbench / skipped transactions
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: dealing with extension dependencies that aren't quite 'e'