Re: Properly handle OOM death?

On 3/13/23 14:50, Israel Brewster wrote:
> Looks like V2:
>
> root(at)novarupta:~# stat -fc %T /sys/fs/cgroup/
> cgroup2fs

Interesting -- it does indeed look like you are using cgroup v2

So the file you want to look at in that case is:
8<-----------
cat
/sys/fs/cgroup/system.slice/system-postgresql.slice/postgresql(at)14(dot)service/memory.max
4294967296

cat
/sys/fs/cgroup/system.slice/system-postgresql.slice/postgresql(at)14(dot)service/memory.high
3221225472
8<-----------
If the value comes back as "max" it means no limit is set.

In this example (on my Linux Mint machine with a custom systemd unit
file) I have memory.max set to 4G and memory.high set to 3G.

The value of memory.max determines when the OOM killer will strike. The
value of memory.high will determine when the kernel goes into aggressive
memory reclaim (trying to avoid memory.max and thus an OOM kill).

The corresponding/relevant systemd unit file parameters are:
8<-----------
MemoryAccounting=yes
MemoryHigh=3G
MemoryMax=4G
8<-----------

There are other ways that memory.max may get set, but it seems most
likely that the systemd unit file is doing it (if it is in fact set).

--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com