> On 17 Aug 2022, at 00:36, i.laza...@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.
