Ha egy AlmaLinux szerveren a free -m kevesebb memóriát mutat, mint amennyi a VPS-csomagban van, az egyik ok a kdump lehet. A kdump egy kernelösszeomlás esetén elmenti a memória tartalmát, hogy utólag kideríthető legyen a hiba oka. Ehhez a rendszerindításkor egy memóriaterületet (crashkernel) tartalékol egy második, úgynevezett mentőkernel számára; ezt a területet a rendszer semmi másra nem használja.

Egy kis VPS-en ez érezhető: egy 2 GB-os gépen az alapértelmezett foglalás 256 MB, a memória nyolcada. A legtöbb weboldalt kiszolgáló szerveren a kdump mentéseit soha senki nem elemzi, így ez a memória jobb helyen van az alkalmazásoknál.

A lépéseket 2026 októberében AlmaLinux 9.8 és 10.2 rendszeren próbáltuk ki, 2 GB memóriájú virtuális gépen.

Van-e foglalás a szerveren?

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

• Ha az első parancs nem ír ki semmit, és a második 0 MB, nincs foglalás, nincs teendő. A teszten az AlmaLinux 9 és 10 cloud image-ével telepített gépeken így volt: a kdump ki volt kapcsolva, crashkernel paraméter nem volt. A telepítőből (ISO-ról) feltelepített rendszereken viszont alapból be van kapcsolva.
• A tényleges foglalást a kernel indítási naplója is mutatja: sudo dmesg | grep -i crashkernel, például crashkernel reserved: 0x00000000a5400000 - 0x00000000b5400000 (256 MB).

Az alapértelmezett érték a memória méretétől függ. A gyári beállítást a sudo kdumpctl get-default-crashkernel írja ki; a teszten AlmaLinux 9 aarch64-en 1G-4G:256M,4G-64G:320M,64G-:576M volt, vagyis 1-4 GB memória mellett 256 MB. x86_64 rendszeren az értékek kisebbek (a Red Hat dokumentációja szerint 1-4 GB-nál 192 MB).

1. lehetőség: kisebb foglalás, a kdump marad

Ha a kdumpot meg szeretné tartani, de kevesebb memóriát szánna rá:

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

A teszten a 2 GB-os gépen ezzel a foglalás 256 MB-ról 128 MB-ra csökkent, a free -m szerinti teljes memória 1699 MB-ról 1827 MB-ra nőtt, és a kdump szolgáltatás továbbra is active volt. Túl kicsi foglalásnál a kdump nem tud elindulni (systemctl status kdump hibát mutat); ilyenkor növelje az értéket.

A gyári értékre a sudo kdumpctl reset-crashkernel --kernel=ALL állítja vissza (újraindítás után érvényes).

2. lehetőség: a kdump kikapcsolása

Ha nincs szüksége a kdumpra, kapcsolja ki, és szüntesse meg a foglalást:

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

A teszten utána a foglalás 0 MB lett, a free -m szerinti teljes memória 1955 MB, vagyis a 256 MB-os foglaláshoz képest 256 MB-tal több.

Két megjegyzés a gyakran olvasható régebbi leírásokhoz:

• A crashkernel=no nem érvényes érték. A teszten a foglalást ugyan megszüntette, de csak azért, mert a kernel nem értette: indításkor ezt naplózta: crashkernel: memory value expected. A paramétert a --remove-args kapcsolóval vegye ki.
• A grub2-mkconfig futtatására nincs szükség: a grubby közvetlenül a rendszerindítási bejegyzéseket módosítja. Ellenőrzés: sudo grubby --info=DEFAULT | grep args.

AlmaLinux 10

A lépések ugyanezek. AlmaLinux 10-en a kdumpctl parancs és a kdump szolgáltatás a kdump-utils csomagban van; ha ez nincs telepítve (a teszten a cloud image-en nem volt), a kdump eleve nem fut, és nincs mit kikapcsolni.

Mikor érdemes megtartani?

Ha a szerver rejtélyesen, nyom nélkül újraindul vagy lefagy, és a hiba okát a Red Hat, az AlmaLinux vagy egy szoftvergyártó támogatásával szeretné kideríteni, a kdump mentése (/var/crash) a legfontosabb nyom. Ilyenkor tartsa meg, legalább a hiba kivizsgálásáig. Ha a memória tartósan szűkös, a foglalás csökkentése helyett gondolja át a VPS-csomag bővítését is; a memóriahiány tüneteiről az Elfogyott a memória: OOM killer és swap fájl cikk ír.