RE: Protect syscache from bloating with negative cache entries - Mailing list pgsql-hackers

From Ideriha, Takeshi
Subject RE: Protect syscache from bloating with negative cache entries
Date
Msg-id 4E72940DA2BF16479384A86D54D0988A6F42725B@G01JPEXMBKW04
Whole thread Raw
In response to RE: Protect syscache from bloating with negative cache entries  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Responses RE: Protect syscache from bloating with negative cache entries  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
List pgsql-hackers
>From: Tsunakawa, Takayuki
>>From: Ideriha, Takeshi [mailto:ideriha.takeshi@jp.fujitsu.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


pgsql-hackers by date:

Previous
From: "Takahashi, Ryohei"
Date:
Subject: RE: SQL statement PREPARE does not work in ECPG
Next
From: Michael Paquier
Date:
Subject: Re: Prepared transaction releasing locks before deregistering its GID