Re: [HACKERS] [GSOC] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions
Thanks for your reply.
Actually, the result of without "rdtsc" is reasonable. I used perf to analyze
the performance and found that
even thought the function tracking conflicts (RWConflictExists) was faster, the
function inserting conflicts (SetRWConflict)
was too slower. According to your suggestion, I found there were much more
waiting events of predicate_lock_manager.
That means, slower SetRWConflict resulted in more lock conflicts.
So I took some effort to made it faster in the last days.
Why the code with "rdtsc" is much faster? I thought that may be caused by some
mistakes.
When I changed a machine to run the code, this phenomenon didn't happen
anymore..
-Original Messages-
From: "Robert Haas"
Sent Time: 2017-07-29 02:46:47 (Saturday)
To: "Mengxing Liu"
Cc: "Alvaro Herrera" , kgrittn ,
"pgsql-hackers@postgresql.org"
Subject: Re: [HACKERS] [GSOC] Eliminate O(N^2) scaling from rw-conflict
tracking in serializable transactions
On Wed, Jul 26, 2017 at 11:41 AM, Mengxing Liu
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.
| benchmarks | without rdtsc | with rdtsc |
| simpe read/write | 4.91 | 14.16 |
| ssibench | 9.72 | 10.24 |
| tpcb | 26.45 | 26.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
--
Sincerely
Mengxing Liu
Re: [HACKERS] [GSOC] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions
On Wed, Jul 26, 2017 at 11:41 AM, Mengxing Liu <
liu-m...@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.
>
> benchmarks without rdtsc with rdtsc
> simpe read/write 4.91 14.16
> ssibench 9.72 10.24
> tpcb 26.45 26.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
[HACKERS] [GSOC] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions
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.
| benchmarks | without rdtsc | with rdtsc |
| simpe read/write | 4.91 | 14.16 |
| ssibench | 9.72 | 10.24 |
| tpcb | 26.45 | 26.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!
BTW, after adding the "rdtsc" instruction, the performance is better than the
original version about 10% at most.
That means, the skip list can work!
Looking forward to your advices.
--
Sincerely
Mengxing Liu
skip-list-for-conflict-tracking.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
