On 2022-May-18, Joe Conway wrote: > On 5/18/22 11:11, Alvaro Herrera wrote:
> > 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. > 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. Well, that means the backend processes don't do their expected task (process some query) but instead they have to do "direct reclaim". I don't know what that is, but it sounds like we'd need to add Linux-specific code in order for this to fix anything. And what would we do in such a situation anyway? Seems like our best hope would be to get malloc() to return NULL and have the resulting transaction abort free enough memory that things in other backends can continue to run. *If* there is a way to have cgroups make Postgres do that, then that would be useful enough. > > 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. I just meant that the cgroup abstraction doesn't offer any interfaces that we can use to improve this, not that we would be running without them. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "How strange it is to find the words "Perl" and "saner" in such close proximity, with no apparent sense of irony. I doubt that Larry himself could have managed it." (ncm, http://lwn.net/Articles/174769/)
