BEZEICHNUNG¶

systemd-oomd.service, systemd-oomd - Ein Abbruch-/Kill-Dienst bei Hauptspeicherengpässen (OOM, Out Of Memory) für den Anwendungsraum

ÜBERSICHT¶

systemd-oomd.service

/lib/systemd/systemd-oomd

BESCHREIBUNG¶

systemd-oomd ist ein Systemdienst, der Cgroups-v2- und Speicherengpassinformationen (PSI) verwendet, um zu überwachen und rechtzeitig Korrekturmaßnahmen zu ergreifen, bevor ein OOM im Kernelraum auftritt.

Sie können die Überwachung von und Aktionen auf Units durch Einstellen von ManagedOOMSwap= und ManagedOOMMemoryPressure= in der Unit-Konfiguration aktivieren, siehe systemd.resource-control(5). systemd-oomd ermittelt Informationen über solche Units von systemd(1), wenn es startet und beobachtet nachfolgende Änderungen.

Cgroups von Units mit auf kill gesetztem ManagedOOMSwap= oder ManagedOOMMemoryPressure= werden überwacht. systemd-oomd fragt regelmäßig PSI-Statistiken für das System und solche Cgroups ab, um zu entscheiden, wann Aktionen erfolgen. Falls die konfigurierten Beschränkungen überschritten wurden, wird systemd-oomd eine Cgroup zur Beendigung auswählen und ein SIGKILL an alle Prozesse darin senden. Beachten Sie, dass nur Nachfahren-Cgroups geeignete Kandidaten zum Töten sind; die Unit, deren Eigenschaft auf kill gesetzt ist, ist kein Kandidat (außer einer seiner Vorfahren setzte seine Eigenschaft auf kill). Auch sind nur Blatt-Cgroups und Cgroups, deren memory.oom.group auf 1 gesetzt ist, geeignete Kandidaten; siehe OOMPolicy= in systemd.service(5).

oomctl(1) kann zum Auflisten beobachteter Cgroups und Druckinformationen verwandt werden.

Siehe oomd.conf(5) für weitere Informationen über die Konfiguration dieses Dienstes.

SYSTEMANFORDERUNGEN UND KONFIGURATION¶

Das System muss Systemd mit einer vollständig vereinheitlichten Cgroup-Hierarchie für die erwarteten Cgroups-v2-Funktionalitäten ausführen. Desweiteren muss die Speicherbuchführung für alle von systemd-oomd überwachten Units eingeschaltet sein. Am einfachsten wird die Speicherbuchführung eingeschaltet, indem in systemd-system.conf(5) der Wert DefaultMemoryAccounting= auf true gesetzt wird.

Der Kernel muss mit PSI-Unterstützung kompiliert worden sein. Diese ist in Linux 4.20 und neuer verfügbar.

Es wird nachdrücklich empfohlen, im System Auslagerungsspeicher zu aktivieren, damit systemd-oomd optimal funktioniert. Mit aktiviertem Auslagerungsspeicher verbringt das System genug Zeit mit dem Auslagern von Speicherseiten, damit systemd-oomd reagieren kann. Ohne Auslagerungsspeicher tritt das System viel schneller in eine Verklemmung im aktiven Betrieb und könnte systemd-oomd daran hindern, in einer vernünftigen Zeit zu reagieren. Siehe "In Verteidigung des Auslagerungsspeichers: typische Missverständnisse"[1] für weitere Details zum Auslagerungsspeicher. Sämtliche Auslagerungs-basierten Aktionen auf Systemen ohne Auslagerungsspeicher werden ignoriert. Während systemd-oomd Speicherdruck-basierte Aktionen auf einem solchen System durchführen kann, wird der Speicherdruck abrupter ansteigen und könnte weitere Anpassungen erfordern, um die gewünschten Schwellwerte und das gewünschte Verhalten zu erreichen.

Beachten Sie, dass es nachdrücklich empfohlen wird, dass Ihre Programme vom Systemd-Benutzerverwalter verwaltet werden, wenn Sie vorhaben, user.slice, user-$UID.slice oder ihre Nachfahren-Cgroups zu überwachen und dort Aktionen durchzuführen, da ansonsten zu viele Prozesse unter dem gleichen Sitzungsbereich laufen (und daher Situationen ermöglicht werden, bei denen intensive Programme systemd-oomd auslösen, so dass es alles unter der Cgroup tötet). Falls Sie eine Desktop-Umgebung wie GNOME oder KDE verwenden, werden bereits viele Sitzungskomponenten mit dem Systemd-Benutzerverwalter gestartet.

EINSATZEMPFEHLUNGEN¶

ManagedOOMSwap= arbeitet mit systemweiten Auslagerungswerten, so dass es am sinnvollsten ist, diese Einstellung in der Wurzelscheibe -.slice zu setzen, womit alle Nachfahren-Cgroups geeignete Kandidaten werden.

ManagedOOMMemoryPressure= arbeitet tendenziell besser bei Cgroups unterhalb der Wurzelscheibe. Für Units, die Prozesse haben, die weniger Latenz-anfällig sind (z.B. system.slice) könnte eine höhere Begrenzung als die Vorgabe von 60 % akzeptabel sein, da solche Prozesse normalerweise Verlangsamungen aufgrund fehlenden Speichers ohne ernsthafte Konsequenzen durchhalten können. Etwas wie user@$UID.service könnte allerdings einen deutlich niedrigeren Wert wie 40 % bevorzugen.

SIEHE AUCH¶

systemd(1), systemd-system.conf(5), systemd.resource-control(5), oomd.conf(5), oomctl(1)

ANMERKUNGEN¶

1.

"In Verteidigung des Auslagerungsspeichers: typische Missverständnisse"

ÜBERSETZUNG¶

Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.

Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.

Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer.