Linux-Speicherverwaltung erklärt: Swap, OOM-Killer und cgroups

Linux geht mit Speicher anders um als die meisten Betriebssysteme. Eine hohe RAM-Auslastung ist nicht immer ein Problem – der Kernel nutzt freien Speicher aktiv für das Caching, um Lesevorgänge von der Festplatte zu beschleunigen. Wenn jedoch echter Speicherdruck entsteht, kommen drei Mechanismen zum Einsatz: Swap, der OOM-Killer und cgroups. Zu verstehen, wie sich jeder dieser Mechanismen verhält und wie man sie konfiguriert, macht den Unterschied zwischen einem Server, der unter Last sanft an Leistung verliert, und einem, der ohne Vorwarnung abstürzt.

Wie Linux Speicherseiten verwaltet

Jeder Prozess läuft in seinem eigenen virtuellen Adressraum, der auf 64-Bit-Systemen bis zu 128 TB groß sein kann. Der Kernel ordnet diese virtuellen Adressen über Seitentabellen dem physischen RAM zu, wobei der Translation Lookaside Buffer (TLB) die letzten Suchvorgänge zwischenspeichert. Ein TLB-Treffer dauert etwa 1 Nanosekunde; ein Fehltreffer kostet 20–100 Nanosekunden, was sich bei speicherintensiven Workloads wie Datenbanken summiert.

Der physische Speicher ist in 4-KB-Seiten unterteilt, und der Kernel teilt diese in zwei Kategorien ein:

• Dateigestützte Seiten – an Dateien auf der Festplatte gebunden. Der Kernel kann saubere Seiten verwerfen oder verschmutzte Seiten in den Auslagerungsspeicher schreiben, ohne dass Swap benötigt wird.
• Anonyme Seiten – Heap- und Stack-Speicher ohne zugehörige Datei. Diese müssen in den Swap geschrieben werden, bevor der Kernel sie freigeben kann.

Auf Servern mit hohem Speicherbedarf führt ein hoher Anteil an anonymen Seiten dazu, dass der Swap-Speicher frühzeitig zum Einsatz kommt. Beobachten Sie den si (swap in) und so (Swap-out) in vmstat 1 — anhaltende Werte ungleich Null sind ein erstes Warnsignal dafür, dass das System unter Druck steht.

Verwenden Sie zur Überwachung das richtige Werkzeug für die Aufgabe:

Ein häufiger Fehler: die free Spalte free -h und in Panik zu geraten. Die available Spalte ist entscheidend. Sie umfasst Speicher, den der Kernel bei Bedarf aus dem Cache zurückgewinnen kann. Ein Server, der nur 512 MB freien, aber 5 GB verfügbaren Speicher anzeigt, ist nicht in Schwierigkeiten.

Wenn der Speicher unter einen Schwellenwert fällt, beginnt der kswapd Daemon beginnt im Hintergrund, Seiten zurückzugewinnen. Reicht das nicht aus, wechselt der Kernel in den Modus der direkten Rückgewinnung und blockiert Prozesse, bis Seiten freigegeben sind. Daher rühren die Latenzspitzen. Richten Sie eine Warnmeldung ein, wenn MemAvailable unter 10–15 % des gesamten RAM fällt, damit Sie Zeit haben, zu reagieren.

Swap konfigurieren

Swap ist ein Bereich auf der Festplatte – entweder eine Partition oder eine Datei –, in den der Kernel inaktive anonyme Seiten verschiebt, wenn der Arbeitsspeicher voll ist. Der Geschwindigkeitsunterschied ist erheblich: DDR4-RAM hat eine Latenz von etwa 100 ns, während NVMe-SSDs bei etwa 100.000 ns und SATA-SSDs bei fast 500.000 ns liegen. Swap ist ein Sicherheitspuffer, kein zusätzlicher RAM. Ein Server, der ständig auf Swap angewiesen ist, hat ein Speicherproblem, das durch mehr Swap nicht behoben werden kann.

Verwenden Sie eine Auslagerungsdatei anstelle einer Partition. Die Größe lässt sich leichter anpassen und es ist keine Neupartitionierung erforderlich.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Fügen Sie die Datei so hinzu /etc/fstab , damit sie auch nach einem Neustart erhalten bleibt. Der chmod 600 Schritt ist erforderlich – alle aus dem RAM ausgelagerten Daten sind aus dem Swap lesbar, daher darf die Datei nicht für alle lesbar sein.

Passen Sie nach dem Erstellen des Swaps vm.swappiness. Der Standardwert von 60 ist sehr aggressiv. Für die meisten Hosting-Workloads sollte der Kernel den RAM bevorzugen und den Swap nur als letzten Ausweg nutzen:

Zur Swap-Größenbestimmung: 1–2 GB reichen für einen 2-GB-VPS aus, der gelegentliche Traffic-Spitzen bewältigt. Auf Systemen mit 8 GB oder mehr ist ein fester Swap von 2–4 GB in der Regel ausreichend. Das Ziel ist es, dem Kernel ein Druckventil für kalte Seiten zu bieten, nicht den gesamten adressierbaren Speicher zu erweitern.

Auf Servern mit begrenztem RAM und reichlich CPU-Leistung erstellt zram einen komprimierten Swap-Bereich im Arbeitsspeicher, wodurch Festplatten-I/O vollständig vermieden wird. Dies ist auf Multi-Tenant-VPS-Hosts zu berücksichtigen, auf denen NVMe von mehreren Mandanten gemeinsam genutzt wird. Achten Sie auf I/O-Konflikte, wenn sich der Swap auf demselben Gerät wie die Datenbankdateien befindet – intensives Swapping und Festplattenschreibvorgänge mit hohem Durchsatz vertragen sich nicht gut.

Der OOM-Killer

Wenn der Kernel den RAM- und Swap-Speicher erschöpft hat und nicht mehr genügend Speicher auf andere Weise freigeben kann, greift der OOM-Killer ein. Er bewertet Prozesse anhand der oom_badness() Funktions:

points = (rss_anon + rss_file + rss_shmem + swapents + pgtables_pages) + (oom_score_adj × totalpages / 1000)

Der Prozess mit der höchsten Punktzahl wird beendet. Die Formel begünstigt Prozesse mit hohem Speicherverbrauch, und der Kernel vermeidet es, mehrere Prozesse kurz nacheinander zu beenden, indem er prüft, ob ein Prozess in den letzten 5 Sekunden bereits beendet wurde.

In den Protokollen erscheinen zwei Arten von OOM-Ereignissen:

• Global OOM – dem gesamten System geht der RAM und der Swap aus. Die Protokolle beginnen mit Out of memory:
• Cgroup-OOM – ein Container oder Dienst hat seine memory.max Limit erreicht. Logs beginnen mit Memory cgroup out of memory:

So überprüfen Sie vergangene OOM-Ereignisse:

dmesg -T | grep -i "out of memory"
journalctl -k --grep="oom"

Achten Sie auf das order Feld in den OOM-Protokollen. Ein Wert über 0 deutet eher auf Speicherfragmentierung als auf vollständige Erschöpfung hin – der Kernel konnte selbst bei verfügbarem freiem Speicher nicht genügend zusammenhängende Seiten finden.

Sie können beeinflussen, auf welche Prozesse der OOM-Killer abzielt, indem Sie /proc/<pid>/oom_score_adj. Der Bereich reicht von -1000 (niemals beenden) bis +1000 (zuerst beenden). Für von systemd verwaltete Dienste legen Sie dies dauerhaft in der Unit-Datei fest:

[Service]
OOMScoreAdjust=-1000

Zusätzliche sysctl-Parameter zur Optimierung des OOM-Verhaltens:

Für eine proaktive Überwachung überprüfen Sie /proc/pressure/memory (Pressure Stall Information, verfügbar seit Kernel 4.20). Beobachten Sie den some avg10 Wert: unter 5 % ist der Zustand stabil, ein anhaltender Wert über 20 % deutet darauf hin, dass ein OOM-Ereignis wahrscheinlich bevorsteht. Ein steigender allocstall Zähler in /proc/vmstat ist ein weiteres Frühwarnsignal – er zählt direkte Speicherfreigabe-Stalls, die oft OOM-Kills vorausgehen. Tools wie systemd-oomd oder earlyoom können bei Erreichen von PSI-Schwellenwerten eingreifen, bevor der OOM-Killer des Kernels anspringt.

Cgroups und Speichergrenzen

Mit Control Groups (Cgroups) können Sie Prozesse in Gruppen organisieren und feste Ressourcenbeschränkungen durchsetzen. Sie wurden in Linux 2.6.24 eingeführt und bilden die Grundlage für Container-Laufzeitumgebungen wie Docker, Podman, Kubernetes und LXC. Der Kernel verfolgt die Speichernutzung pro Cgroup und erfasst dabei anonymen Speicher, dateibasierte Seiten und Kernel-Objekte. Wenn eine Cgroup ihr Limit erreicht, gewinnt der Kernel Speicher innerhalb dieser Gruppe zurück oder löst einen Cgroup-spezifischen OOM-Kill aus.

Cgroup v1 und v2 unterscheiden sich in erster Linie in ihrer Struktur. V1 bindet jeden Controller (Speicher, CPU, E/A) separat unter /sys/fs/cgroup/<controller>/, was zu einer inkonsistenten Ressourcenverfolgung führt. V2 verwendet eine einheitliche Hierarchie unter /sys/fs/cgroup/. Kubernetes hat in Version 1.25 standardmäßig auf v2 umgestellt und die Unterstützung für v1 in 1.31 eingestellt.

So überprüfen Sie, welche Version Ihr System verwendet:

stat -fc %T /sys/fs/cgroup/

cgroup2fs bedeutet v2; tmpfs bedeutet in der Regel v1.

Die wichtigsten Speichersteuerungen in cgroup v2:

Eine praktische Regel: Setze memory.high etwa 10–20 % darunter memory.max , um dem Kernel Spielraum für Rückgewinnung zu geben, bevor das harte Limit erreicht wird. Bei der Dimensionierung memory.max, addieren Sie 20–30 % über der Spitzenauslastung der Anwendung hinzu, um den Seiten-Cache zu berücksichtigen, der auf die Gesamtspeichermenge der cgroup angerechnet wird.

Verwalten Sie cgroups über systemd, anstatt direkt in das cgroup-Dateisystem zu schreiben. Verwenden Sie Unit-Datei-Direktiven wie MemoryMax=, MemoryHigh=und MemoryMin= für dauerhafte Limits. Für schnelle Tests:

systemd-run --scope -p MemoryMax=512M <command>

Für Webserver-Worker-Pools stellt die Einstellung memory.oom.group=1 ein sauberes Beenden, wenn ein Worker sein Limit überschreitet – es bleiben keine verwaisten Prozesse zurück. Für Datenbank-Engines schützt memory.min schützt den Pufferpool davor, unter systemweiter Last zurückgewonnen zu werden.

Speicherkonfiguration nach Serverrolle

Die richtigen Speichereinstellungen hängen davon ab, welche Aufgaben der Server erfüllt. Die Anwendung derselben Konfiguration auf eine Datenbank und einen PHP-Webserver würde einem der beiden schaden.

Weisen Sie für MySQL und PostgreSQL 50–70 % des verfügbaren RAM zu innodb_buffer_pool_size, deaktivieren Sie Transparent Huge Pages, um Latenzspitzen zu reduzieren, und schützen Sie den Prozess mit OOMScoreAdjust=-900 in der systemd-Unit-Datei.

Für PHP-FPM sollten Sie die Größe der Worker-Pools an der tatsächlichen Speicherauslastung ausrichten. Jeder Worker benötigt in der Regel 30–100 MB. Teilen Sie den zugewiesenen Arbeitsspeicher durch die durchschnittliche Worker-Größe, um einen sicheren pm.max_children Wert zu erhalten. Verwenden Sie memory.max in cgroups, um den Pool zu begrenzen.

Bei schreibintensiven Workloads vm.dirty_ratio auf etwa 10 % und vm.dirty_background_ratio auf 3 %. Dadurch werden geänderte Seiten häufiger geleert, wodurch große I/O-Verzögerungen vermieden werden.

Machen Sie die Kernel-Optimierung dauerhaft, indem Sie die Parameter in /etc/sysctl.d/90-memory.conf. Einstellungen, die zur Laufzeit angewendet werden, gehen beim Neustart verloren.

Eine Übersicht über die empfohlenen Werte nach Rolle:

Wenn Sie Workloads mit hoher Auslastung ausführen und einen Server mit ausreichender Leistungsreserve benötigen, um diese Richtlinien ordnungsgemäß anzuwenden, sind die dedizierten Server von FDC einen Blick wert.