| From: | "Ideriha, Takeshi" <ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com> |
|---|---|
| To: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, "'Kyotaro HORIGUCHI'" <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
| Cc: | "alvherre(at)2ndquadrant(dot)com" <alvherre(at)2ndquadrant(dot)com>, "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>, "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-21 05:41:56 |
| Message-ID: | 4E72940DA2BF16479384A86D54D0988A6F42725B@G01JPEXMBKW04 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>From: Tsunakawa, Takayuki
>>From: Ideriha, Takeshi [mailto:ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com]
>> number of tables | 100 |1000 |10000
>> -----------------------------------------------------------
>> TPS (master) |10966 |10654 |9099
>> TPS (patch) | 11137 (+1%) |10710 (+0%) |772 (-91%)
>>
>> It seems that before cache exceeding the limit (no pruning at 100 and
>> 1000), the results are almost same with master but after exceeding the
>> limit (at
>> 10000)
>> the decline happens.
>
>How many concurrent clients?
One client (default setting).
>Can you show the perf's call graph sampling profiles of both the unpatched and
>patched version, to confirm that the bottleneck is around catcache eviction and refill?
I checked it with perf record -avg and perf report.
The following shows top 20 symbols during benchmark including kernel space.
The main difference between master (unpatched) and patched one seems that
patched one consumes cpu catcache-evict-and-refill functions including
SearchCatCacheMiss(), CatalogCacheCreateEntry(), CatCacheCleanupOldEntries().
So it seems to me that these functions needs further inspection
to suppress the performace decline as much as possible
Master(%) master |patch (%) patch
51.25% cpu_startup_entry | 51.45% cpu_startup_entry
51.13% arch_cpu_idle | 51.19% arch_cpu_idle
51.13% default_idle | 51.19% default_idle
51.13% native_safe_halt | 50.95% native_safe_halt
36.27% PostmasterMain | 46.98% PostmasterMain
36.27% main | 46.98% main
36.27% __libc_start_main | 46.98% __libc_start_main
36.07% ServerLoop | 46.93% ServerLoop
35.75% PostgresMain | 46.89% PostgresMain
26.03% exec_simple_query | 45.99% exec_simple_query
26.00% rest_init | 43.40% SearchCatCacheMiss
26.00% start_kernel | 42.80% CatalogCacheCreateEntry
26.00% x86_64_start_reservations | 42.75% CatCacheCleanupOldEntries
26.00% x86_64_start_kernel | 27.04% rest_init
25.26% start_secondary | 27.04% start_kernel
10.25% pg_plan_queries | 27.04% x86_64_start_reservations
10.17% pg_plan_query | 27.04% x86_64_start_kernel
10.16% main | 24.42% start_secondary
10.16% __libc_start_main | 22.35% pg_analyze_and_rewrite
10.03% standard_planner | 22.35% parse_analyze
Regards,
Takeshi Ideriha
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2019-02-21 05:54:31 | Re: Prepared transaction releasing locks before deregistering its GID |
| Previous Message | Takahashi, Ryohei | 2019-02-21 05:41:51 | RE: SQL statement PREPARE does not work in ECPG |