Re: slab allocator performance issues

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org, Tomas Vondra <tv(at)fuzzy(dot)cz>
Subject: Re: slab allocator performance issues
Date: 2021-08-03 13:33:28
Message-ID: 5d83ac71-9054-208d-a48a-24d9d6b61f55@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

FWIW I tried running the benchmarks again, with some minor changes in
the extension code - most importantly, the time is counted in microsecs
(instead of milisecs).

I suspected the rounding might have been causing some rounding errors
(essentially not counting anything below 1ms, because it rounds to 0),
and the results are a bit different.

On the i5-2500k machine it's an improvement across the board, while on
the bigger Xeon e5-2620v3 machine it shows roughly the same regression
for the "decreasing" allocation pattern.

There's another issue in the benchmarking script - the queries are meant
to do multiple runs for each combination of parameters, but it's written
in a way that simply runs it once and then does cross product with the
generate_sequence(1,5). I'll look into fixing that, but judging by the
stability of results for similar chunk sizes it won't change much.

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Attachment Content-Type Size
0001-slab-bench-v2.patch text/x-patch 17.3 KB
0002-WIP-optimize-allocations-by-separating-hot-from-c-v2.patch text/x-patch 31.7 KB
0003-WIP-slab-performance-v2.patch text/x-patch 23.4 KB
slab i5.ods application/vnd.oasis.opendocument.spreadsheet 587.8 KB
slab xeon.ods application/vnd.oasis.opendocument.spreadsheet 593.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-08-03 13:39:50 Re: [PATCH] proposal for regexp_count, regexp_instr, regexp_substr and regexp_replace
Previous Message Justin Pryzby 2021-08-03 13:10:09 Re: when the startup process doesn't (logging startup delays)