Re: Protect syscache from bloating with negative cache entries

At Tue, 26 Jan 2021 11:43:21 +0200, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote in
> Hi,
>
> On 19/11/2020 07:25, Kyotaro Horiguchi wrote:
> > Performance measurement on the attached showed better result about
> > searching but maybe worse for cache entry creation. Each time number
> > is the mean of 10 runs.
> > # Cacache (negative) entry creation
> > : time(ms) (% to master)
> > master : 3965.61 (100.0)
> > patched-off: 4040.93 (101.9)
> > patched-on : 4032.22 (101.7)
> > # Searching negative cache entries
> > master : 8173.46 (100.0)
> > patched-off: 7983.43 ( 97.7)
> > patched-on : 8049.88 ( 98.5)
> > # Creation, searching and expiration
> > master : 6393.23 (100.0)
> > patched-off: 6527.94 (102.1)
> > patched-on : 15880.01 (248.4)
> > That is, catcache searching gets faster by 2-3% but creation gets
> > slower by about 2%. If I moved the condition of 2 further up to
> > CatalogCacheCreateEntry(), that degradation reduced to 0.6%.
> > # Cacache (negative) entry creation
> > master : 3967.45 (100.0)
> > patched-off : 3990.43 (100.6)
> > patched-on : 4108.96 (103.6)
> > # Searching negative cache entries
> > master : 8106.53 (100.0)
> > patched-off : 8036.61 ( 99.1)
> > patched-on : 8058.18 ( 99.4)
> > # Creation, searching and expiration
> > master : 6395.00 (100.0)
> > patched-off : 6416.57 (100.3)
> > patched-on : 15830.91 (247.6)
>
> Can you share the exact script or steps to reproduce these numbers? I
> presume these are from the catcachebench extension, but I can't figure
> out which scenario above corresponds to which catcachebench
> test. Also, catcachebench seems to depend on a bunch of tables being
> created in schema called "test"; what tables did you use for the above
> numbers?

gen_tbl.pl to generate the tables, then run2.sh to run the
benchmark. sumlog.pl to summarize the result of run2.sh.

$ ./gen_tbl.pl | psql postgres
$ ./run2.sh | tee rawresult.txt | ./sumlog.pl

(I found a bug in a benchmark-aid function
(CatalogCacheFlushCatalog2), I repost an updated version soon.)

Simple explanation follows since the scripts are a kind of crappy..

run2.sh:
LOOPS : # of execution of catcachebench() in a single run
USES : Take the average of this number of fastest executions in a
single run.
BINROOT : Common parent directory of target binaries.
DATADIR : Data directory. (shared by all binaries)
PREC : FP format for time and percentage in a result.
TESTS : comma-separated numbers given to catcachebench.

The "run" function spec

run "binary-label" <binary-path> <A> <B> <C>
where A, B and C are the value for catalog_cache_prune_min_age. ""
means no setting (used for master binary). Currently only C is in
effect but all the three should be non-empty string to make it
effective.

The result output is:

test | version | n | r | stddev
------+-------------+-----+----------+---------
1 | patched-off | 1/3 | 14211.96 | 261.19

test : # of catcachebench(#)
version: binary label given to the run function
n : USES / LOOPS
r : result average time of catcachebench() in milliseconds
stddev : stddev of

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center