From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Tomas Vondra <tv@fuzzy.cz>
Subject: Re: slab allocator performance issues
Date: Mon, 2 Aug 2021 00:01:25 +0200
Message-ID: <76ebb476-4060-393b-5bf1-0287ae1464bd@enterprisedb.com> (raw)
In-Reply-To: <20210801210722.kctrnyxwwu4mzail@alap3.anarazel.de>
References: <20210717194333.mr5io3zup3kxahfm@alap3.anarazel.de>
<c3bf99d3-0dec-828e-e3b5-ed2d2922bdd8@enterprisedb.com>
<20210717211405.3ocp2rpxlnozg3tq@alap3.anarazel.de>
<02ff3ced-3212-aea1-c7a0-4829f43e58d2@enterprisedb.com>
<20210717231019.blfhyqniu6jed3ym@alap3.anarazel.de>
<20210718010600.fat2f5j4gvqig56j@alap3.anarazel.de>
<37dc9b41-dd75-251d-a77e-16c72c794b00@enterprisedb.com>
<20210719205603.lzh5rkuv7lsoq4mp@alap3.anarazel.de>
<6717ca90-a2ea-b17d-f544-37f5181b1175@enterprisedb.com>
<20210801210722.kctrnyxwwu4mzail@alap3.anarazel.de>
On 8/1/21 11:07 PM, Andres Freund wrote:
> Hi,
>
> On 2021-08-01 19:59:18 +0200, Tomas Vondra wrote:
>> In the attached .ods file with results, the "comparison" sheets are the
>> interesting ones - the last couple columns compare the main metrics for the
>> two patches (labeled patch-1 and patch-2) to master.
>
> I assume with patch-1/2 you mean the ones after the benchmark patch
> itself?
>
Yes, those are the two WIP patches you shared on 19/7.
>
>> Overall, the results look quite good - patch-1 is mostly on par with master,
>> with maybe 5% variability in both directions. That's expected, considering
>> the patch does not aim to improve performance.
>
> Not for slab anyway...
>
Maybe the hot/cold separation could have some effect, but probably not
for the workloads I've tested.
>
>> The second patch brings some nice improvements - 30%-50% in most cases (for
>> both allocation and free) seems pretty nice. But for the "increase" FIFO
>> pattern (incrementally allocating/freeing more memory) there's a significant
>> regression - particularly for the allocation time. In some cases (larger
>> chunks, block size does not matter too much) it jumps from 25ms to almost
>> 200ms.
>
> I'm not surprised to see some memory usage increase some, but that
> degree of time overhead does surprise me. ISTM there's something wrong.
>
Yeah, the higher amount of allocated memory is due to the couple fields
added to the SlabBlock struct, but even that only affects a single case
with 480B chunks and 1kB blocks. Seems fine to me, especially if we end
up growing the slab blocks.
Not sure about the allocation time, though.
> It'd probably worth benchmarking the different improvements inside the
> WIP: slab performance. patch. There's some that I'd expect to be all
> around improvements, whereas others likely aren't quite that clear
> cut. I assume you'd prefer that I split the patch up?
>
Yeah, if you split that patch into sensible parts, I'll benchmark those.
Also, we can add more interesting workloads if you have some ideas.
>
>> This seems unfortunate - the allocation pattern (FIFO, allocating more
>> memory over time) seems pretty common, and the slowdown is significant.
>
> Did you analyze what causes the regressions?
>
No, not yet. I'll run the same set of benchmarks for the Generation,
discussed in the other thread, and then I'll investigate this. But if
you split the patch, that'd probably help.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tomas.vondra@enterprisedb.com, andres@anarazel.de, tv@fuzzy.cz
Subject: Re: slab allocator performance issues
In-Reply-To: <76ebb476-4060-393b-5bf1-0287ae1464bd@enterprisedb.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox