From b750101eb236130cf056c675997decbac904cc49 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sun, 7 Apr 2024 17:35:18 +0200 Subject: Adding upstream version 252.22. Signed-off-by: Daniel Baumann --- man/systemd-oomd.service.xml | 114 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 114 insertions(+) create mode 100644 man/systemd-oomd.service.xml (limited to 'man/systemd-oomd.service.xml') diff --git a/man/systemd-oomd.service.xml b/man/systemd-oomd.service.xml new file mode 100644 index 0000000..11c9237 --- /dev/null +++ b/man/systemd-oomd.service.xml @@ -0,0 +1,114 @@ + + + + + + + + systemd-oomd.service + systemd + + + + systemd-oomd.service + 8 + + + + systemd-oomd.service + systemd-oomd + A userspace out-of-memory (OOM) killer + + + + systemd-oomd.service + /usr/lib/systemd/systemd-oomd + + + + Description + + systemd-oomd is a system service that uses cgroups-v2 and pressure stall + information (PSI) to monitor and take corrective action before an OOM occurs in the kernel space. + + You can enable monitoring and actions on units by setting ManagedOOMSwap= and + ManagedOOMMemoryPressure= in the unit configuration, see + systemd.resource-control5. + systemd-oomd retrieves information about such units from systemd + when it starts and watches for subsequent changes. + + Cgroups of units with ManagedOOMSwap= or + ManagedOOMMemoryPressure= set to will be monitored. + systemd-oomd periodically polls PSI statistics for the system and those cgroups to + decide when to take action. If the configured limits are exceeded, systemd-oomd will + select a cgroup to terminate, and send SIGKILL to all processes in it. Note that + only descendant cgroups are eligible candidates for killing; the unit with its property set to + is not a candidate (unless one of its ancestors set their property to + ). Also only leaf cgroups and cgroups with memory.oom.group set + to 1 are eligible candidates; see OOMPolicy= in + systemd.service5. + + + oomctl1 can + be used to list monitored cgroups and pressure information. + + See oomd.conf5 + for more information about the configuration of this service. + + + + System requirements and configuration + + 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.conf5. + + The kernel must be 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" 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 such a + system, 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 or KDE, 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. 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 + + systemd1, + systemd-system.conf5, + systemd.resource-control5, + oomd.conf5, + oomctl1 + + + -- cgit v1.2.3