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
