From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | robertmhaas(at)gmail(dot)com |
Cc: | ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com, tomas(dot)vondra(at)2ndquadrant(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, andres(at)anarazel(dot)de, tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com, alvherre(at)2ndquadrant(dot)com, bruce(at)momjian(dot)us, pgsql-hackers(at)lists(dot)postgresql(dot)org, michael(dot)paquier(at)gmail(dot)com, david(at)pgmasters(dot)net, craig(at)2ndquadrant(dot)com |
Subject: | Re: Protect syscache from bloating with negative cache entries |
Date: | 2019-04-05 08:32:12 |
Message-ID: | 20190405.173212.12490045.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Fri, 05 Apr 2019 09:44:07 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <20190405(dot)094407(dot)151644324(dot)horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
> By the way, I found the reason of the wrong result of the
> previous benchmark. The test 3_0/1 needs to update catcacheclock
> midst of the loop. I'm going to fix it and rerun it.
I found the cause. CataloCacheFlushCatalog() doesn't shring the
hash. So no resize happens once it is bloated. I needed another
version of the function that reset the cc_bucket to the initial
size.
Using the new debug function, I got better numbers.
I focused on the performance when disabled. I rechecked that by
adding the patch part-by-part and identified several causes of
the degradaton. I did:
- MovedpSetCatCacheClock() to AtStart_Cache()
- Maybe improved the caller site of CatCacheCleanupOldEntries().
As the result:
binary | test | count | avg | stddev |
--------+------+-------+---------+--------+-------
master | 1_1 | 5 | 7104.90 | 4.40 |
master | 2_1 | 5 | 3759.26 | 4.20 |
master | 3_1 | 5 | 7954.05 | 2.15 |
--------+------+-------+---------+--------+-------
Full | 1_1 | 5 | 7237.20 | 7.98 | 101.87
Full | 2_1 | 5 | 4050.98 | 8.42 | 107.76
Full | 3_1 | 5 | 8192.87 | 3.28 | 103.00
But, still fluctulates by around 5%..
If this level of the degradation is still not acceptable, that
means that nothing can be inserted in the code path and the new
code path should be isolated from existing code by using indirect
call.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Attachment | Content-Type | Size |
---|---|---|
v17-0001-Remove-entries-that-haven-t-been-used-for-a-certain-.patch | text/x-patch | 6.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Banck | 2019-04-05 08:39:26 | Re: pg_rewind vs superuser |
Previous Message | Magnus Hagander | 2019-04-05 08:11:22 | Re: pg_rewind vs superuser |