>
> 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
RAID10SSD).
>
Thanks for testing and especially for the flame graph. That is somewhat in between the cases that I have tested. On
commodityserver with dual Xeon (6C each) 2pc speed is about 80% of 1pc speed, but on 60C/120T system that patch didn’t
makesignificant 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
usingincrementing 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@2ndquadrant.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.
ButJesper’s flame graph on 24 core system shows different picture.
> On 12 Jan 2016, at 01:24, Andres Freund <andres@anarazel.de> wrote:
>
> Currently recovery of 2pc often already is a bigger bottleneck than the workload on the master, because replay has to
executethe 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
soslow. I’m now working on that.
Stas Kelvich
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company