| From: | "Ideriha, Takeshi" <ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com> |
|---|---|
| To: | 'Kyotaro HORIGUCHI' <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "alvherre(at)2ndquadrant(dot)com" <alvherre(at)2ndquadrant(dot)com> |
| Cc: | "tomas(dot)vondra(at)2ndquadrant(dot)com" <tomas(dot)vondra(at)2ndquadrant(dot)com>, "bruce(at)momjian(dot)us" <bruce(at)momjian(dot)us>, "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, "robertmhaas(at)gmail(dot)com" <robertmhaas(at)gmail(dot)com>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, "michael(dot)paquier(at)gmail(dot)com" <michael(dot)paquier(at)gmail(dot)com>, "david(at)pgmasters(dot)net" <david(at)pgmasters(dot)net>, "craig(at)2ndquadrant(dot)com" <craig(at)2ndquadrant(dot)com> |
| Subject: | RE: Protect syscache from bloating with negative cache entries |
| Date: | 2019-02-08 09:42:20 |
| Message-ID: | 4E72940DA2BF16479384A86D54D0988A6F41EDD1@G01JPEXMBKW04 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>From: Kyotaro HORIGUCHI [mailto:horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)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)
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?
># I'm not sure the name LRU_IGNORANCE_INTERVAL makes sens..
How about MIN_LRU_UPDATE_INTERVAL?
Regards,
Takeshi Ideriha
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2019-02-08 10:00:40 | Re: pgsql: Restrict the use of temporary namespace in two-phase transaction |
| Previous Message | Peter Eisentraut | 2019-02-08 09:41:59 | Re: pgsql: Restrict the use of temporary namespace in two-phase transaction |