Wenn auf einem AlmaLinux-Server der Befehl „free -m“ weniger Arbeitsspeicher anzeigt, als im VPS-Paket enthalten ist, kann dies unter anderem an einem „kdump“ liegen. Der „kdump“ speichert im Falle eines Kernelabsturzes den Speicherinhalt, damit die Ursache des Fehlers nachträglich ermittelt werden kann. Zu diesem Zweck reserviert das System beim Systemstart einen Speicherbereich („crashkernel“) für einen zweiten, sogenannten „Rettungskernel“; dieser Bereich wird vom System für keine anderen Zwecke genutzt.

Auf einem kleinen VPS macht sich dies bemerkbar: Bei einem 2-GB-Server beträgt die standardmäßige Zuweisung 256 MB, also ein Achtel des Arbeitsspeichers. Auf den meisten Servern, die Websites hosten, werden die kdump-Sicherungen von niemandem analysiert, sodass dieser Arbeitsspeicher bei den Anwendungen besser aufgehoben ist.

Wir haben die Schritte im Oktober 2026 auf den Systemen AlmaLinux 9.8 und 10.2 auf einer virtuellen Maschine mit 2 GB Arbeitsspeicher getestet.

Gibt es eine Reservierung auf dem Server?

grep -o 'crashkernel=[^ ]*' /proc/cmdline
echo $(( $(cat /sys/kernel/kexec_crash_size) / 1048576 )) MB
systemctl is-enabled kdump

• Wenn der erste Befehl keine Ausgabe liefert und der zweite „0 MB“ anzeigt, liegt keine Belegung vor, und es sind keine Maßnahmen erforderlich. Bei den im Test verwendeten Rechnern, die mit den Cloud-Images von AlmaLinux 9 und 10 installiert wurden, war dies der Fall: „kdump“ war deaktiviert, und der Parameter „crashkernel“ war nicht vorhanden. Bei Systemen, die über das Installationsprogramm (von der ISO-Datei) installiert wurden, ist diese Funktion hingegen standardmäßig aktiviert.
• Die tatsächliche Belegung wird auch im Kernel-Startprotokoll angezeigt: sudo dmesg | grep -i crashkernel, beispielsweise crashkernel reserved: 0x00000000a5400000 - 0x00000000b5400000 (256 MB).

Der Standardwert hängt von der Speichergröße ab. Die Werkseinstellung wird mit dem Befehl „sudo kdumpctl get-default-crashkernel“ ausgegeben; im Test lag der Wert unter AlmaLinux 9 aarch64 bei „1G-4G:256M,4G-64G:320M,64G-:576M“, d. h. 256 MB bei 1–4 GB Arbeitsspeicher. Auf x86_64-Systemen sind die Werte geringer (laut Red Hat-Dokumentation 192 MB bei 1–4 GB).

1. Möglichkeit: geringere Reservierung, der kdump bleibt erhalten

Wenn Sie den Kdump behalten möchten, dafür aber weniger Speicherplatz dafür aufwenden möchten:

sudo grubby --update-kernel=ALL --args="crashkernel=1G-4G:128M,4G-64G:192M,64G-:256M"
sudo reboot

Im Test sank bei dem 2-GB-Rechner die Speicherbelegung von 256 MB auf 128 MB, der gesamte Speicher gemäß „free -m“ stieg von 1699 MB auf 1827 MB, und der Dienst „kdump“ war weiterhin active. Bei einer zu geringen Speicherbelegung kann „kdump“ nicht gestartet werden (systemctl status kdump zeigt einen Fehler an); erhöhen Sie in diesem Fall den Wert.

Der Standardwert wird mit dem Befehl „sudo kdumpctl reset-crashkernel --kernel=ALL“ wiederhergestellt (gilt erst nach einem Neustart).

2. Möglichkeit: Deaktivierung von „kdump“

Falls Sie den kdump nicht benötigen, deaktivieren Sie ihn bitte und heben Sie die Reservierung auf:

sudo systemctl disable --now kdump
sudo grubby --update-kernel=ALL --remove-args="crashkernel"
sudo reboot

Nach dem Test betrug die belegte Speichermenge 0 MB, die gesamte Speichermenge laut „free -m“ 1955 MB, also 256 MB mehr als die belegte Speichermenge von 256 MB.

Zwei Anmerkungen zu den häufig gelesenen älteren Anleitungen:

• „crashkernel=no“ ist kein gültiger Wert. Im Test wurde die Reservierung zwar aufgehoben, jedoch nur, weil der Kernel den Wert nicht verstanden hat: Beim Start wurde Folgendes protokolliert: „crashkernel: memory value expected“. Entfernen Sie den Parameter mit dem Schalter „--remove-args“.
• Die Ausführung von „grub2-mkconfig“ ist nicht erforderlich: „grubby“ ändert die Boot-Einträge direkt. Überprüfung: „sudo grubby --info=DEFAULT | grep args“.

AlmaLinux 10

Die Schritte sind dieselben. Unter AlmaLinux 10 befinden sich der Befehl „kdumpctl“ und der Dienst „kdump“ im Paket „kdump-utils“; ist dieses nicht installiert (im Test war es auf dem Cloud-Image nicht vorhanden), läuft „kdump“ von vornherein nicht, und es gibt nichts, was deaktiviert werden müsste.

Wann ist es sinnvoll, diese beizubehalten?

Sollte der Server auf mysteriöse Weise und ohne erkennbaren Grund neu starten oder einfrieren und Sie die Ursache des Fehlers mit Unterstützung von Red Hat, AlmaLinux oder einem Softwarehersteller ermitteln möchten, ist die kdump-Sicherung (/var/crash) der wichtigste Anhaltspunkt. Bewahren Sie diese in einem solchen Fall zumindest bis zur Klärung des Fehlers auf. Sollte der Arbeitsspeicher dauerhaft knapp sein, sollten Sie statt einer Reduzierung der Speicherbelegung auch eine Erweiterung Ihres VPS-Pakets in Betracht ziehen; über die Symptome eines Arbeitsspeichermangels informiert der Artikel „Arbeitsspeicher erschöpft: OOM-Killer und Swap-Datei“.