At Fri, 8 Feb 2019 09:42:20 +0000, "Ideriha, Takeshi" <ideriha.take...@jp.fujitsu.com> wrote in <4E72940DA2BF16479384A86D54D0988A6F41EDD1@G01JPEXMBKW04> > >From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp] > >I made a rerun of benchmark using "-S -T 30" on the server build with no > >assertion and > >-O2. The numbers are the best of three successive attempts. The patched > >version is > >running with cache_target_memory = 0, cache_prune_min_age = 600 and > >cache_entry_limit = 0 but pruning doesn't happen by the workload. > > > >master: 13393 tps > >v12 : 12625 tps (-6%) > > > >Significant degradation is found. > > > >Recuded frequency of dlist_move_tail by taking 1ms interval between two > >succesive > >updates on the same entry let the degradation dissapear. > > > >patched : 13720 tps (+2%) > > It would be good to introduce some interval. > I followed your benchmark (initialized scale factor=10 and others are same > option) > and found the same tendency. > These are average of 5 trials. > master: 7640.000538 > patch_v12:7417.981378 (3 % down against master) > patch_v13:7645.071787 (almost same as master)
Thank you for cross checking. > These cases are not pruning happen workload as you mentioned. > I'd like to do benchmark of cache-pruning-case as well. > To demonstrate cache-pruning-case > right now I'm making hundreds of partitioned table and run select query for > each partitioned table > using pgbench custom file. Maybe using small number of cache_prune_min_age or > hard limit would be better. > Are there any good model? As per Tomas' benchmark, it doesn't seem to harm for the case. > ># I'm not sure the name LRU_IGNORANCE_INTERVAL makes sens.. > How about MIN_LRU_UPDATE_INTERVAL? Looks fine. Fixed in the next version. Thank you for the suggestion. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
