Re: [HACKERS] [GSOC] Eliminate O(N^2) scaling from rw-conflicttracking in serializable transactions

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] [GSOC] Eliminate O(N^2) scaling from rw-conflicttracking in serializable transactions
Дата
Msg-id CA+Tgmoa4qoxwdDvKpE1=HSw4Xk2u3y7MZYksnMxJ9LTRxMWHrw@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] [GSOC] Eliminate O(N^2) scaling from rw-conflict tracking inserializable transactions  ("Mengxing Liu" <liu-mx15@mails.tsinghua.edu.cn>)
Ответы Re: [HACKERS] [GSOC] Eliminate O(N^2) scaling from rw-conflicttracking in serializable transactions  ("Mengxing Liu" <liu-mx15@mails.tsinghua.edu.cn>)
Список pgsql-hackers
Дерево обсуждения
On Wed, Jul 26, 2017 at 11:41 AM, Mengxing Liu <liu-mx15@mails.tsinghua.edu.cn> wrote:
Hi, all. There was a very strange phenomenon I couldn't explain. So I was wondering if you can help me.

I was trying to replace the linked list with a skip list in serializable transaction object for faster conflict tracking. But the performance is bad.
So I used the instruction "rdtsc" to compare the speed of my skip list and the original linked list. The skip list was about 1.5x faster.

The interesting thing is that if I added the instruction "rdstc" at the end of the function "RWConflictExists", 
the performance of the whole system was increased by at most 3 times! 
Here is the result. 

benchmarkswithout rdtsc with rdtsc
simpe read/write4.9114.16
ssibench9.7210.24
tpcb26.4526.38

( The simple read/write benchmark has the most number of conflicts. )

The patch is attached. All the difference of the two columns is with/without a simple line of code:
__asm__ __volatile__ ("rdtsc"); 
But I don't know why this instruction will influence the performance so much!

Lock contention is really expensive, so a slight delay that is just long enough to prevent the contention from happening can sometimes improve performance.  This example is surprisingly dramatic, though.  Of course, we can't commit it this way -- it will break on non-x86.

I would suggest that you gather information on what wait events are occurring in the "without rdtsc" case.  Like this:

$ script
$ psql
psql=> select wait_event from pg_stat_activity;
psql=> \watch 0.5
...run test in another window...
^C
\q
^D
...use awk or perl or something to count up the wait events and see where the contention is happening...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] segfault in HEAD when too many nested functions call
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] map_partition_varattnos() and whole-row vars