On Tue, Apr 19, 2016 at 8:41 PM, Kevin Grittner <kgri...@gmail.com> wrote: > > On Tue, Apr 19, 2016 at 9:57 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Sun, Apr 17, 2016 at 2:26 AM, Andres Freund <and...@anarazel.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
old_snapshot_threshold_perf_issue_v1.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
