Re: Safe vm.overcommit_ratio for Large Multi-Instance PostgreSQL Fleet

Thank you for your message Frederic,

I am very much aware of that issue. It’s actually incorrect to say that is a bug: that is how cgroupsv1, which is
bundledwith rhel8, works. However, it is very counter intuitive. For that reason redhat created the
force_cgroup_v2_swappinessparameter uniquely theirselves, it’s not a common Linux parameter. 

The specific issue I see in certain cases leading to unreasonable swap usage is Linux workingset detection kicking in,
whichcan choose anonymous memory despite having lots of file memory available, leading to swapping, which sometimes
leadsto a thrashing situation. 

It is funny to see how emotional people react to removing swap, and how people go through great efforts to carefully
tryingwrap that in a technical reason or point to people having said something that agrees with their emotion. I should
saythat I understand the reluctance, it’s not weird to feel anxious. 

The kernel has no inherent swap requirement. Of course, removing swap cannot be blindly applied, you have to carefully
makeit suit your environment, usage and intention. And there ARE cases where swap makes sense (if you have memory usage
thatexceeds physical memory, and you add enough swap to sustain that). But a database in general typically responds bad
toswapping (or anything that fluctuates latency), and when swap removal is sensibly done, it prevents anonymous
(includinglesser frequently used ;-)) memory from getting swapped.  

I will not convince everybody, but I hope I can make some people that understand the technology thinking about it and
considerthe arguments. 

Friendly regards,

Frits



>
> Op 18 aug 2025 om 18:17 heeft Frédéric Yhuel <frederic.yhuel@dalibo.com> het volgende geschreven:
>
> 
>
>> On 8/8/25 10:21, Frits Hoogland wrote:
>> If swappiness is set to 0, but swap is available, some documentation suggests it will never use anonymous memory,
howeverI found this not to be true, linux might still choose anonymous memory to reclaim. 
>
>
> A bug in RHEL8 meant that swappiness was not taken into account unless cgroupv2 was configured or
vm.force_cgroup_v2_swappinesswas set to 1. See references [1] and [2]. Could this be the cause of your observation? 
>
> [1] https://access.redhat.com/solutions/6785021
> [2] https://github.com/systemd/systemd/issues/9276