On Wed, Dec 9, 2015 at 10:44 AM, Stas Kelvich <s.kelvich@postgrespro.ru> wrote:
> Hello.
>
> While working with cluster stuff (DTM, tsDTM) we noted that postgres 2pc transactions is approximately two times
slowerthan an ordinary commit on workload with fast transactions — few single-row updates and COMMIT or PREPARE/COMMIT.
Perftop showed that a lot of time is spent in kernel on fopen/fclose, so it worth a try to reduce file operations with
2pctx.
>
I've tested this through my testing harness which forces the database
to go through endless runs of crash recovery and checks for
consistency, and so far it has survived perfectly.
...
>
> Now results of benchmark are following (dual 6-core xeon server):
>
> Current master without 2PC: ~42 ktps
> Current master with 2PC: ~22 ktps
> Current master with 2PC: ~36 ktps
Can you give the full command line? -j, -c, etc.
>
> Benchmark done with following script:
>
> \set naccounts 100000 * :scale
> \setrandom from_aid 1 :naccounts
> \setrandom to_aid 1 :naccounts
> \setrandom delta 1 100
> \set scale :scale+1
Why are you incrementing :scale ?
I very rapidly reach a point where most of the updates are against
tuples that don't exist, and then get integer overflow problems.
> BEGIN;
> UPDATE pgbench_accounts SET abalance = abalance - :delta WHERE aid = :from_aid;
> UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :to_aid;
> PREPARE TRANSACTION ':client_id.:scale';
> COMMIT PREPARED ':client_id.:scale';
>
Cheers,
Jeff