Re: Move PinBuffer and UnpinBuffer to atomics

On 2016-04-11 14:40:29 -0700, Andres Freund wrote:
> On 2016-04-11 12:17:20 -0700, Andres Freund wrote:
> > On 2016-04-11 22:08:15 +0300, Alexander Korotkov wrote:
> > > On Mon, Apr 11, 2016 at 5:04 PM, Alexander Korotkov <
> > > a(dot)korotkov(at)postgrespro(dot)ru> wrote:
> > >
> > > > On Mon, Apr 11, 2016 at 8:10 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > > >
> > > >> Could you retry after applying the attached series of patches?
> > > >>
> > > >
> > > > Yes, I will try with these patches and snapshot too old reverted.
> > > >
> > >
> > > I've run the same benchmark with 279d86af and 848ef42b reverted. I've
> > > tested of all 3 patches from you applied and, for comparison, 3 patches +
> > > clog buffers reverted back to 32.
> > >
> > > clients patches patches + clog_32
> > > 1 12594 12556
> > > 2 26705 26258
> > > 4 50985 53254
> > > 8 103234 104416
> > > 10 135321 130893
> > > 20 268675 267648
> > > 30 370437 409710
> > > 40 486512 482382
> > > 50 539910 525667
> > > 60 616401 672230
> > > 70 667864 660853
> > > 80 924606 737768
> > > 90 1217435 799581
> > > 100 1326054 863066
> > > 110 1446380 980206
> > > 120 1484920 1000963
> > > 130 1512440 1058852
> > > 140 1536181 1088958
> > > 150 1504750 1134354
> > > 160 1461513 1132173
> > > 170 1453943 1158656
> > > 180 1426288 1120511
>
> > Any chance that I could run some tests on that machine myself? It's very
> > hard to investigate that kind of issue without access; the only thing I
> > otherwise can do is lob patches at you, till we find the relevant
> > memory.
>
> I did get access to the machine (thanks!). My testing shows that
> performance is sensitive to various parameters influencing memory
> allocation. E.g. twiddling with max_connections changes
> performance. With max_connections=400 and the previous patches applied I
> get ~1220000 tps, with 402 ~1620000 tps. This sorta confirms that we're
> dealing with an alignment/sharing related issue.
>
> Padding PGXACT to a full cache-line seems to take care of the largest
> part of the performance irregularity. I looked at perf profiles and saw
> that most cache misses stem from there, and that the percentage (not
> absolute amount!) changes between fast/slow settings.
>
> To me it makes intuitive sense why you'd want PGXACTs to be on separate
> cachelines - they're constantly dirtied via SnapshotResetXmin(). Indeed
> making it immediately return propels performance up to 1720000, without
> other changes. Additionally cacheline-padding PGXACT speeds things up to
> 1750000 tps.
>
> But I'm unclear why the magnitude of the effect depends on other
> allocations. With the previously posted patches allPgXact is always
> cacheline-aligned.

Oh, one more thing: The volatile on PGXACT in GetSnapshotData() costs us
about 100k tps on that machine; without, afaics, any point but force
pgxact->xmin to only be loaded once (which a *((volatile
TransactionId)&pgxact->xmin) does just as well).

Greetings,

Andres Freund