On 5/18/22 11:11, Alvaro Herrera wrote:
> Now that's where cgroup's memory limiting features would prove useful,
> if they weren't totally braindead:
> https://www.kernel.org/doc/Documentation/cgroup-v2.txt
> Apparently, if the cgroup goes over the "high" limit, the processes are
> *throttled*. Then if the group goes over the "max" limit, OOM-killer is
> invoked.
>
> (I can't see any way to make this even more counterproductive to the
> database use case. Making the database work more slowly doesn't fix
> anything.)
You may be misinterpreting "throttle" in this context. From [1]:
The memory.high boundary on the other hand can be set
much more conservatively. When hit, it throttles
allocations by forcing them into direct reclaim to
work off the excess, but it never invokes the OOM
killer.
> So ditch cgroups.
You cannot ditch cgroups if you are running in a container. And in fact
most non-container installations these days are also running in a cgroup
under systemd.
The only difference is that you are more likely to see a memory limit
set in a container than under systemd.
[1]
https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/cgroup-v2.rst
--
Joe Conway
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com