Hi Manu,
Thanks for the quick response. Attached v4 with both points: the systemd
OOMPolicy note, and the oom_score_adj -1000 exemption for the group
kill, with a pointer to the overcommit section. I also resolved the ambiguity
that arose after this new insertion.
Regards,
João Marcelo
Hi João,
Thanks for v3. The new sentence is right, and the docs build. Going
through the whole section once more, two cases behave differently
from what it says; I should have raised them with v2.
> If that is a server process other than the postmaster, the
> postmaster treats it as a crash and, unless restart_after_crash is
> turned off, restarts all server processes, disconnecting all sessions.
Not when the server runs as a systemd service, which is a common way
to set a memory limit outside containers. systemd's OOMPolicy applies
too, and its default, stop, stops the whole service after an OOM kill.
With MemoryMax=400M and no OOMPolicy set, two of three runs ended with
"received smart shutdown request" and the unit in the oom-kill failed
state, and the third was already deactivating; with
OOMPolicy=continue, the postmaster restarted all three times. Perhaps
add:
If the server runs as a systemd service, systemd's OOMPolicy setting
also applies; its default, stop, stops the whole service instead.
> If memory.oom.group is set for the cgroup, [...] the OOM killer
> instead terminates all processes of the cgroup, including the
> postmaster.
The kernel exempts processes whose oom_score_adj is -1000 from the
group kill, and that is what linux-memory-overcommit recommends for
the postmaster. With the postmaster at -1000 and memory.oom.group set
to 1, the group kill happened but the postmaster survived and
restarted the other processes, in three runs out of three. Inside a
container the postmaster usually cannot lower its own score, so the
Kubernetes case stays as you describe. Perhaps:
... the OOM killer instead terminates all processes of the cgroup
except those with an oom_score_adj of -1000, so the postmaster too,
unless it is protected as described in
<xref linkend="linux-memory-overcommit"/>.
Regards,
Manu
