Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
Subject: Re: MultiXact\SLRU buffers configuration
From: Andrey Borodin <x4mmm@yandex-team.ru>
In-Reply-To: <452d01f7e331458f56ad79bef537c31b@postgrespro.ru>
Date: Thu, 18 Aug 2022 08:35:15 +0500
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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6BABE00C-64BD-4F5D-A071-32B42FAAEB76@yandex-team.ru>
References: 
 <CA+hUKGKEdeVKpOqBxzRF+Z4=j0T+CA7ERrXni5De71Mm6-dBWA@mail.gmail.com>
 <27D90FFC-B897-4BC5-B4F5-9047B9886AA3@yandex-team.ru>
 <CA+hUKGKTESKn9-BkUT8T3vwcgZQJqsV4PSQKpE+M1qUgfSTLMg@mail.gmail.com>
 <B7D61584-6CAC-4CF9-B3D4-7CC52D6C4C5C@yandex-team.ru>
 <15CA416B-3446-462D-902B-4883DD3ADEE6@yandex-team.ru>
 <CA+hUKGLCLDtgDj2Xsf0uBk5WXDCeHxBDDJPsyY7m65Fde-=pyg@mail.gmail.com>
 <B8FACD14-E3AB-4EB3-8CCC-E93697C54F72@yandex-team.ru>
 <CA+hUKGKzPSXYowH=Y8NiuUD8gdyD225-WHaEzXT1E0Sa8RopVQ@mail.gmail.com>
 <3130B767-FEB7-4F18-AE90-DD95B4367316@yandex-team.ru>
 <CA+hUKGLZWwv6Vwq0E8XxK+YZHEbt7Z=KBQagfXhyEquz52WXDA@mail.gmail.com>
 <20220219214223.w4bmhiozeimcqhzb@alap3.anarazel.de>
 <01FF6FFC-7379-43EA-B04A-673C98ABFAAF@yandex-team.ru>
 <e46cdea96979545b2d8a13b451d8b1ce61dc7238.camel@postgrespro.ru>
 <E6EEC639-9B91-4FB6-A857-96B17E9900ED@yandex-team.ru>
 <452d01f7e331458f56ad79bef537c31b@postgrespro.ru>
To: i.lazarev@postgrespro.ru
Archived-At: 
 <https://www.postgresql.org/message-id/6BABE00C-64BD-4F5D-A071-32B42FAAEB76%40yandex-team.ru>
Precedence: bulk


> On 17 Aug 2022, at 00:36, i.lazarev@postgrespro.ru wrote:
>=20
>> 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.
>=20
> Hi @Andrey.Borodin, With some considerations and performance checks =
from @Yura.Sokolov we simplified your approach by the following:
>=20
> 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.
>=20
> 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.=