Re: MultiXact\SLRU buffers configuration
x4mmm@yandex-team.ru
From: Andrey Borodin <x4mmm@yandex-team.ru>
To: i.lazarev@postgrespro.ru
Cc: Yura Sokolov <y.sokolov@postgrespro.ru>,
Andres Freund <andres@anarazel.de>,
Thomas Munro <thomas.munro@gmail.com>,
Gilles Darold <gilles@darold.net>,
Tomas Vondra <tomas.vondra@enterprisedb.com>,
Tomas Vondra <tomas.vondra@2ndquadrant.com>,
Alexander Korotkov <aekorotkov@gmail.com>,
Anastasia Lubennikova <a.lubennikova@postgrespro.ru>,
Daniel Gustafsson <daniel@yesql.se>,
Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-08-18T03:35:15Z
Lists: pgsql-hackers
> On 17 Aug 2022, at 00:36, i.lazarev@postgrespro.ru wrote: > >> Andrey Borodin wrote 2022-07-23 11:39: >> Yura, thank you for your benchmarks! >> We already knew that patch can save the day on pathological workloads, >> now we have a proof of this. >> Also there's the evidence that user can blindly increase size of SLRU >> if they want (with the second patch). So there's no need for hard >> explanations on how to tune the buffers size. > > Hi @Andrey.Borodin, With some considerations and performance checks from @Yura.Sokolov we simplified your approach by the following: > > 1. Preamble. We feel free to increase any SLRU's, since there's no performance degradation on large Buffers count using your SLRU buckets solution. > 2. `slru_buffers_size_scale` is only one config param introduced for all SLRUs. It scales SLRUs upper cap by power 2. > 3. All SLRU buffers count are capped by both `MBuffers (shared_buffers)` and `slru_buffers_size_scale`. see > 4. Magic initial constants `NUM_*_BUFFERS << slru_buffers_size_scale` are applied for every SLRU. > 5. All SLRU buffers are always sized as power of 2, their hash bucket size is always 8. > > There's attached patch for your consideration. It does gather and simplify both `v21-0001-Make-all-SLRU-buffer-sizes-configurable.patch` and `v21-0002-Divide-SLRU-buffers-into-8-associative-banks.patch` to much simpler approach. I like the idea of one knob instead of one per each SLRU. Maybe we even could deduce sane value from NBuffers? That would effectively lead to 0 knobs :) Your patch have a prefix "v22-0006", does it mean there are 5 previous steps of the patchset? Thank you! Best regards, Andrey Borodin.
Commits
-
Rework new SLRU test with injection points
- 94a3373ac5c3 18.0 landed
-
injection_point: Add injection_points.stats
- 2e35c67f9568 18.0 landed
-
injection_points: Add initialization of shmem state when loading module
- b2b023aa3706 18.0 landed
-
Add injection-point test for new multixact CV usage
- 768a9fd5535f 18.0 landed
-
Use conditional variable to wait for next MultiXact offset
- a0e0fb1ba56f 17.0 landed
-
Improve performance of subsystems on top of SLRU
- 53c2a97a9266 17.0 landed
-
Adjust VACUUM hastup LP_REDIRECT comments.
- 325bc54eed4e 16.0 cited
-
Test replay of regression tests, attempt II.
- f47ed79cc8a0 15.0 cited