RE: Protect syscache from bloating with negative cache entries

From: "Ideriha, Takeshi" <ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com>
To: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "PostgreSQL Hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, 'Robert Haas' <robertmhaas(at)gmail(dot)com>, "David Steele" <david(at)pgmasters(dot)net>, Craig Ringer <craig(at)2ndquadrant(dot)com>
Subject: RE: Protect syscache from bloating with negative cache entries
Date: 2019-03-04 03:03:51
Message-ID: 4E72940DA2BF16479384A86D54D0988A6F44564E@G01JPEXMBKW04
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

>From: Tsunakawa, Takayuki [mailto:tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com]

>> [Size=800, iter=1,000,000]
>> Master |15.763
>> Patched|16.262 (+3%)
>> [Size=32768, iter=1,000,000]
>> Master |61.3076
>> Patched|62.9566 (+2%)
>What's the unit, second or millisecond?

>Why is the number of digits to the right of the decimal point?
>Is the measurement correct? I'm wondering because the difference is larger in the
>latter case. Isn't the accounting processing almost the same in both cases?
>* former: 16.262 - 15.763 = 4.99
>* latter: 62.956 - 61.307 = 16.49
>I think the overhead is sufficiently small. It may get even smaller with a trivial tweak.
>You added the new member usedspace at the end of MemoryContextData. The
>original size of MemoryContextData is 72 bytes, and Intel Xeon's cache line is 64 bytes.
>So, the new member will be on a separate cache line. Try putting usedspace before
>the name member.

OK. I changed the order of MemoryContextData members to fit usedspace into one cacheline.
I disabled all the catcache eviction mechanism in patched one and compared it with master
to investigate that overhead of memory accounting become small enough.

The settings are almost same as the last email.
But last time the number of trials was 50 so I increased it and tried 5000 times to
calculate the average figure (rounded off to three decimal place).
[Size=800, iter=1,000,000]
Master |15.64 ms
Patched|16.26 ms (+4%)
The difference is 0.62ms

[Size=32768, iter=1,000,000]
Master |61.39 ms
Patched|60.99 ms (-1%)

I guess there is around 2% noise.
But based on this experiment it seems the overhead small.
Still there is some overhead but it can be covered by some other
manipulation like malloc().

Does this result show that hard-limit size option with memory accounting
doesn't harm to usual users who disable hard limit size option?

Takeshi Ideriha

Attachment Content-Type Size
v15-0001-3-Add-dlist_move_tail.patch application/octet-stream 1.2 KB
v15-0002-3-ideriha-Memory-consumption-report-reature-of-memorycontext.patch application/octet-stream 3.6 KB
v15-0003-3-ideriha-Remove-CatCache-Entries.patch application/octet-stream 23.4 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-03-04 03:06:16 Re: Online verification of checksums
Previous Message Michael Paquier 2019-03-04 03:01:35 Re: pg_partition_tree crashes for a non-defined relation