Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <

On Tue, Apr 19, 2016 at 8:41 PM, Kevin Grittner <kgrittn(at)gmail(dot)com> wrote:
>
> On Tue, Apr 19, 2016 at 9:57 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:
> > On Sun, Apr 17, 2016 at 2:26 AM, Andres Freund <andres(at)anarazel(dot)de>
wrote:
> >>
> >> On 2016-04-16 16:44:52 -0400, Noah Misch wrote:
> >> > That is more controversial than the potential ~2% regression for
> >> > old_snapshot_threshold=-1. Alvaro[2] and Robert[3] are okay
releasing
> >> > that way, and Andres[4] is not.
> >>
> >> FWIW, I could be kinda convinced that it's temporarily ok, if there'd
be
> >> a clear proposal on the table how to solve the scalability issue around
> >> MaintainOldSnapshotTimeMapping().
> >
> > It seems that for read-only workloads, MaintainOldSnapshotTimeMapping()
> > takes EXCLUSIVE LWLock which seems to be a probable reason for a
performance
> > regression. Now, here the question is do we need to acquire that lock
if
> > xmin is not changed since the last time value of
> > oldSnapshotControl->latest_xmin is updated or xmin is lesser than equal
to
> > oldSnapshotControl->latest_xmin?
> > If we don't need it for above cases, I think it can address the
performance
> > regression to a good degree for read-only workloads when the feature is
> > enabled.
>
> Thanks, Amit -- I think something along those lines is the right
> solution to the scaling issues when the feature is enabled.
>

I have tried attached patch along the above lines and it seems that it
addresses performance regression to a good degree when feature is enabled
at moderate client-count like 32, but still more needs to be done for
somewhat higher client-count like 64.

Performance data is for median of 3, 5 min runs of read-only workload -
pgbench -c $client_count -j $client_count -T 300 -M prepared -S postgres

o_s_t - old_snapshot_threshold

Client_Count/Patch_Ver 32 64
HEAD (o_s_t = -1) 354077 552063
HEAD (o_s_t = 1) 92809 55847
Patch (o_s_t = 1) 319759 191741

If you think that attached patch is correct functionality wise, then I
think we can go-ahead with it and then investigate what more can be
improved. I think newly introduced spinlocks might be the reason of
performance degradation at higher client-count, if that turns out to be
true, then I think we can replace them with atomics, once Andres's patch
for completing the 64-bit atomics implementation is committed.

m/c details used for performance testing
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 192
On-line CPU(s) list: 0-191
Thread(s) per core: 8
Core(s) per socket: 1
Socket(s): 24
NUMA node(s): 4
Model: IBM,8286-42A
L1d cache: 64K
L1i cache: 32K
L2 cache: 512K
L3 cache: 8192K
NUMA node0 CPU(s): 0-47
NUMA node1 CPU(s): 48-95
NUMA node2 CPU(s): 96-143
NUMA node3 CPU(s): 144-191

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com