At Fri, 8 Feb 2019 09:42:20 +0000, "Ideriha, Takeshi" <ideriha.takeshi@jp.fujitsu.com> wrote in
<4E72940DA2BF16479384A86D54D0988A6F41EDD1@G01JPEXMBKW04>
> >From: Kyotaro HORIGUCHI [mailto:horiguchi.kyotaro@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