Re: MultiXact\SLRU buffers configuration
От | Andrey M. Borodin |
---|---|
Тема | Re: MultiXact\SLRU buffers configuration |
Дата | |
Msg-id | 2087E87D-44CA-4443-8E6A-5087F07443F4@yandex-team.ru обсуждение исходный текст |
Ответ на | Re: MultiXact\SLRU buffers configuration (Anastasia Lubennikova <a.lubennikova@postgrespro.ru>) |
Ответы |
Re: MultiXact\SLRU buffers configuration
Re: MultiXact\SLRU buffers configuration |
Список | pgsql-hackers |
Hi, Anastasia! > 28 авг. 2020 г., в 23:08, Anastasia Lubennikova <a.lubennikova@postgrespro.ru> написал(а): > > 1) The first patch is sensible and harmless, so I think it is ready for committer. I haven't tested the performance impact,though. > > 2) I like the initial proposal to make various SLRU buffers configurable, however, I doubt if it really solves the problem,or just moves it to another place? > > The previous patch you sent was based on some version that contained changes for other slru buffers numbers: 'multixact_offsets_slru_buffers'and 'multixact_members_slru_buffers'. Have you just forgot to attach them? The patch message"[PATCH v2 2/4]" hints that you had 4 patches) > Meanwhile, I attach the rebased patch to calm down the CFbot. The changes are trivial. > > 2.1) I think that both min and max values for this parameter are too extreme. Have you tested them? > > + &multixact_local_cache_entries, > + 256, 2, INT_MAX / 2, > > 2.2) MAX_CACHE_ENTRIES is not used anymore, so it can be deleted. > > 3) No changes for third patch. I just renamed it for consistency. Thank you for your review. Indeed, I had 4th patch with tests, but these tests didn't work well: I still did not manage to stress SLRUs to reproduceproblem from production... You are absolutely correct in point 2: I did only tests with sane values. And observed extreme performance degradation withvalues ~ 64 megabytes. I do not know which highest values should we pick? 1Gb? Or highest possible functioning value? I greatly appreciate your review, sorry for so long delay. Thanks! Best regards, Andrey Borodin.
В списке pgsql-hackers по дате отправления: