Re: Speedup twophase transactions
Jesper Pedersen <jesper.pedersen@redhat.com>
From: Jesper Pedersen <jesper.pedersen@redhat.com>
To: Stas Kelvich <s.kelvich@postgrespro.ru>
Cc: Simon Riggs <simon@2ndQuadrant.com>, Andres Freund <andres@anarazel.de>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2016-01-12T14:48:05Z
Lists: pgsql-hackers
Attachments
- 1pc.svg.gz (application/gzip)
- 2pc.svg.gz (application/gzip)
On 01/11/2016 06:11 PM, Stas Kelvich wrote: >> On 11 Jan 2016, at 21:40, Jesper Pedersen <jesper.pedersen@redhat.com> wrote: >> I have done a run with the patch and it looks really great. >> >> Attached is the TPS graph - with a 1pc run too - and the perf profile as a flame graph (28C/56T w/ 256Gb mem, 2 x RAID10 SSD). >> > > Thanks for testing and especially for the flame graph. That is somewhat in between the cases that I have tested. On commodity server with dual Xeon (6C each) 2pc speed is about 80% of 1pc speed, but on 60C/120T system that patch didn’t make significant difference because main bottleneck changes from file access to locks on array of running global transactions. > > How did you generated names for your PREPARE’s? One funny thing that I’ve spotted that tx rate increased when i was using incrementing counter as GID instead of random string. > I'm using https://github.com/jesperpedersen/postgres/tree/pgbench_xa - so just the client_id. The strcmp() in MarkAsPreparing() is under the exclusive lock, so maybe that is what you are seeing, as shorter gid's are faster. > And can you also share flame graph for 1pc workload? > Attached with a new 2pc, as the server runs Linux 4.4.0 now, both using -F 497 over a 6 min run. Best regards, Jesper
Commits
-
Speedup 2PC recovery by skipping two phase state files in normal path
- 728bd991c3c4 10.0 landed
-
Add tests for two-phase commit
- 30820982b295 10.0 landed
-
Improve grammar of message about two-phase state files.
- 38c363adf497 10.0 landed
-
Speedup 2PC by skipping two phase state files in normal path
- 978b2f65aa12 9.6.0 cited