Re: Speedup twophase transactions

From: Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru>
To: Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, Simon Riggs <simon(at)2ndQuadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Speedup twophase transactions
Date: 2016-01-11 23:11:12
Message-ID: 9FD75684-B7B7-4A76-BF6D-9349CDE09A80@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> On 11 Jan 2016, at 21:40, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)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.

And can you also share flame graph for 1pc workload?

>
> On 11 Jan 2016, at 21:43, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
> Have you measured lwlocking as a problem?
>

Yes. GXACT locks that wasn’t even in perf top 10 on dual Xeon moves to the first places when running on 60 core system. But Jesper’s flame graph on 24 core system shows different picture.

> On 12 Jan 2016, at 01:24, Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Currently recovery of 2pc often already is a bigger bottleneck than the workload on the master, because replay has to execute the fsyncs implied by statefile re-creation serially, whereas on the master they'll usually be executed in parallel.

That’s interesting observation. Simon already pointed me to this problem in 2pc replay, but I didn’t thought that it is so slow. I’m now working on that.

Stas Kelvich
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2016-01-11 23:31:30 Re: Fuzzy substring searching with the pg_trgm extension
Previous Message Elvis Pranskevichus 2016-01-11 22:56:32 pg_dump fails on domain constraint comments