Re: MultiXact\SLRU buffers configuration
x4mmm@yandex-team.ru
From: Andrey Borodin <x4mmm@yandex-team.ru>
To: Gilles Darold <gilles@darold.net>
Cc: 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: 2021-02-15T17:17:40Z
Lists: pgsql-hackers
Attachments
- v9-0001-Make-all-SLRU-buffer-sizes-configurable.patch (application/octet-stream) patch v9-0001
> 23 дек. 2020 г., в 21:31, Gilles Darold <gilles@darold.net> написал(а): > > Sorry for the response delay, we have run several others tests trying to figure out the performances gain per patch but unfortunately we have very heratic results. With the same parameters and patches the test doesn't returns the same results following the day or the hour of the day. This is very frustrating and I suppose that this is related to the Azure architecture. The only thing that I am sure is that we had the best performances results with all patches and > > multixact_offsets_slru_buffers = 256 > multixact_members_slru_buffers = 512 > multixact_local_cache_entries = 4096 > > > but I can not say if all or part of the patches are improving the performances. My feeling is that performances gain related to patches 1 (shared lock) and 3 (conditional variable) do not have much to do with the performances gain compared to just tuning the multixact buffers. This is when the multixact contention is observed but perhaps they are delaying the contention. It's all the more frustrating that we had a test case to reproduce the contention but not the architecture apparently. Hi! Thanks for the input. I think we have a consensus here that configuring SLRU size is beneficial for MultiXacts. There is proposal in nearby thread [0] on changing default value of commit_ts SLRU buffers. In my experience from time to time there can be problems with subtransactions cured by extending subtrans SLRU. Let's make all SLRUs configurable? PFA patch with draft of these changes. Best regards, Andrey Borodin. [0] https://www.postgresql.org/message-id/flat/20210115220744.GA24457%40alvherre.pgsql
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