SYSTEMD-OOMD.SERVICE(8) systemd-oomd.service SYSTEMD-OOMD.SERVICE(8)
NAME
systemd-oomd.service, systemd-oomd - A userspace out-of-memory (OOM)
killer
SYNOPSIS
systemd-oomd.service
/lib/systemd/systemd-oomd
DESCRIPTION
systemd-oomd is a system service that uses cgroups-v2 and pressure
stall information (PSI) to monitor and take action on processes before
an OOM occurs in kernel space.
You can enable monitoring and actions on units by setting
ManagedOOMSwap= and/or ManagedOOMMemoryPressure= to the appropriate
value. systemd-oomd will periodically poll enabled units' cgroup data
to detect when corrective action needs to occur. When an action needs
to happen, it will only be performed on the descendant cgroups of the
enabled units. More precisely, only cgroups with memory.oom.group set
to 1 and leaf cgroup nodes are eligible candidates. Action will be
taken recursively on all of the processes under the chosen candidate.
See oomd.conf(5) for more information about the configuration of this
service.
SETUP INFORMATION
The system must be running systemd with a full unified cgroup hierarchy
for the expected cgroups-v2 features. Furthermore, memory accounting
must be turned on for all units monitored by systemd-oomd. The easiest
way to turn on memory accounting is by ensuring the value for
DefaultMemoryAccounting= is set to true in systemd-system.conf(5).
You will need a kernel compiled with PSI support. This is available in
Linux 4.20 and above.
It is highly recommended for the system to have swap enabled for
systemd-oomd to function optimally. With swap enabled, the system
spends enough time swapping pages to let systemd-oomd react. Without
swap, the system enters a livelocked state much more quickly and may
prevent systemd-oomd from responding in a reasonable amount of time.
See "In defence of swap: common misconceptions"[1] for more details on
swap. Any swap-based actions on systems without swap will be ignored.
While systemd-oomd can perform pressure-based actions on a system
without swap, the pressure increases will be more abrupt and may
require more tuning to get the desired thresholds and behavior.
Be aware that if you intend to enable monitoring and actions on
user.slice, user-$UID.slice, or their ancestor cgroups, it is highly
recommended that your programs be managed by the systemd user manager
to prevent running too many processes under the same session scope (and
thus avoid a situation where memory intensive tasks trigger
systemd-oomd to kill everything under the cgroup). If you're using a
desktop environment like GNOME, it already spawns many session
components with the systemd user manager.
USAGE RECOMMENDATIONS
ManagedOOMSwap= works with the system-wide swap values, so setting it
on the root slice -.slice, and allowing all descendant cgroups to be
eligible candidates may make the most sense.
ManagedOOMMemoryPressure= tends to work better on the cgroups below the
root slice -.slice. For units which tend to have processes that are
less latency sensitive (e.g. system.slice), a higher limit like the
default of 60% may be acceptable, as those processes can usually ride
out slowdowns caused by lack of memory without serious consequences.
However, something like user@$UID.service may prefer a much lower value
like 40%.
SEE ALSO
systemd(1), systemd-system.conf(5), systemd.resource-control(5),
oomd.conf(5), oomctl(1)
NOTES
1. "In defence of swap: common misconceptions"
https://chrisdown.name/2018/01/02/in-defence-of-swap.html
systemd 249 SYSTEMD-OOMD.SERVICE(8)
Generated by dwww version 1.14 on Thu Jan 23 06:38:26 CET 2025.