Re: Properly handle OOM death?

On 3/13/23 13:55, Israel Brewster wrote:
> 1) They reference a “Memory cgroup out of memory”, which refers back
> to the opening comment on Joe Conway’s message - this would imply to
> me that I *AM* running with a cgroup memory.limit set. Not sure how
> that changes things?

cgroup memory limit is enforced regardless of the actual host level 
memory pressure. As an example, if your host VM has 128 GB of memory, 
but your cgroup memory limit is 512MB, you will get an OOM kill when the 
sum memory usage of all of your postgres processes (and anything else 
sharing the same cgroup) exceeds 512 MB, even if the host VM has nothing 
else going on consuming memory.

You can check if a memory is set by reading the corresponding virtual 
file, e.g:

8<-------------------
# cat 
/sys/fs/cgroup/memory/system.slice/postgresql.service/memory.limit_in_bytes
9223372036854710272
8<-------------------

A few notes:
1/ The specific path to memory.limit_in_bytes might vary, but this 
example is the default for the RHEL 8 postgresql 10 RPM.

2/ The value above, 9223372036854710272 basically means "no limit" has 
been set.

3/ The example assumes cgroup v1. There are very few distro's that 
enable cgroup v2 by default, and generally I have not seen much cgroup 
v2 usage in the wild (although I strongly recommend it), but if you are 
using cgroup v2 the names have changed. You can check by doing:

8<--cgroupv2 enabled-----------------
# stat -fc %T /sys/fs/cgroup/
cgroup2fs
8<--cgroupv1 enabled-----------------
# stat -fc %T /sys/fs/cgroup/
tmpfs
8<-------------------

> 2) All the entries contain the line "oom_score_adj:0”, which would
> seem to imply that the postmaster, with its -900 score is not being
> directly targeted by the OOM killer.

Sounds correct

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