Linux OOM killer beállítás VPS-hez

A Linux OOM killer a kernel utolsó eszköze, amikor elfogy a memória: kiválaszt egy folyamatot, és leállítja azt, hogy a rendszer tovább működhessen. Egy VPS-en, ahol a RAM szűkös, és nincs hova visszavonulni, az alapértelmezett választás gyakran helytelen. Az adatbázisod leáll, egy régóta futó munkaprogram viszont tovább működik, és neked kell kitalálnod, hogy miért. Ez az útmutató bemutatja, hogyan értékeli az OOM killer a folyamatokat, hogyan lehet ezt az értékelést a kritikus szolgáltatások felé terelni, és hogyan lehet a cgroups-okat használni, hogy egy egyetlen elszabadult folyamat ne tudja magával rántani a rendszer többi részét.

Hogyan választja ki az OOM killer az áldozatot

Amikor a kernel nem tud elegendő memóriát visszanyerni a lapozócache-ből való kiszorítással vagy a swap használatával, akkor az OOM killert hívja meg. Minden folyamatnak van egy oom_score 0 és 1000 közötti pontszámmal rendelkezik, amely főként a Resident Set Size (RSS) és a swap-használat alapján kerül kiszámításra. A legmagasabb pontszámmal rendelkező folyamat SIGKILL-t kap.

Az RSS dominál a számításban, ezért a kill szinte mindig a legnagyobb memóriafogyasztót éri el. Ez gyakran az adatbázis, az alkalmazásszerver vagy bármelyik hosszú élettartamú folyamat, amely a leghasznosabb munkát végzi. Az a folyamat, amely ténylegesen kiváltotta az allokációt, az „invoker”, ritkán az, amelyet leállítanak.

Kétféle OOM eseményt kell megkülönböztetni:

• Globális OOM: a gazdagép (vagy a VPS egészében) elfogyott a RAM és a swap. A kernel átvizsgálja az összes folyamatot, és leállítja a legmagasabb pontszámot elérőt.
• Cgroup OOM: egy adott cgroup elérte a memóriahatárát. A kernel csak azon a cgroupon belül szüntet meg folyamatokat, még akkor is, ha a rendszer többi részében van szabad memória.

Ha beállította a systemd egységkorlátokat, vagy konténereket futtat, az OOM események többsége cgroup OOM lesz. Ez jó dolog: a hatástér korlátozott.

A memória terhelés észlelése a leállás előtt

Az OOM események szinte soha nem hirtelenek. Általában először egy növekvő terhelésű időszak következik be, és a monitorozás célja, hogy ezt az időszakot kiszűrje.

free -h a rendszer nézetét mutatja. A fontos oszlop a available, nem pedig free: ez a visszanyerhető oldalkészletet mutatja, és azt tükrözi, hogy mit tud ténylegesen allokálni swapolás nélkül. Tartsa MemAvailable körülbelül 10–15 százalékos szinten MemTotal a csúcsterhelés idején.

A folyamatonkénti hozzárendeléshez rendezze RSS szerint:

ps aux --sort=-%mem | head -10

Vagy használja htop és rendezés RES. Az itt látható értékek közvetlenül bekerülnek a kernel pontozásába, így a legfelső bejegyzések a legvalószínűbb OOM célpontok.

A 4.20-as és újabb kernelen a Pressure Stall Information az a korai figyelmeztető rendszer, amelyet érdemes beépíteni a monitorozásba:

cat /proc/pressure/memory

A some avg10 ábra azt mutatja, hogy az elmúlt tíz másodpercben mennyi százalékban állt le legalább egy feladat a memória várakozása miatt. 5 százalék alatt nincs gond. A 10 százalék feletti tartós értékek azt jelentik, hogy a rendszer valós időt tölt el a memória visszanyerésével, és valószínű az OOM kill.

A swap thrashing a vmstat 1 nem nulla si és so oszlopokban jelenik meg, amelyek időben tartósak. Kis mennyiségű rezidens swap ártalmatlan. Az állandó swap-in és swap-out viszont nem az.

Kritikus folyamatok védelme az oom_score_adj segítségével

A kernel által kiszámított pontszám folyamatonként módosítható az oom_score_adj, -1000 (immunis) és +1000 (először engem ölj meg) közötti skálán. A kiigazítás közvetlenül hozzáadódik a végső pontszámhoz.

Egyszeri módosítás futó folyamat esetén:

echo -500 | sudo tee /proc/$(pidof sshd)/oom_score_adj

Ha valamit az újraindítások után is meg akarsz tartani, állítsd be a systemd egységben. Ez a megfelelő hely az sshd-nek, az adatbázisodnak és minden másnak, amit nem engedhetsz meg magadnak, hogy elveszíts:

[Service]
OOMScoreAdjust=-900

Ésszerű alapértelmezett értékek a kezdéshez:

• sshd: -1000. Ha memóriahiány miatt elveszíted a távoli hozzáférést, a helyreállítás sokkal nehezebb lesz.
• MySQL, PostgreSQL, Redis: -800 és -900 között. Erős védelem anélkül, hogy valóban katasztrofális helyzetben teljesen érinthetetlenné tenné őket.
• Alkalmazás-munkások, kötegelt feladatok, cron-feladatok: +100 és +500 között. Ezek azok a folyamatok, amelyeket inkább látnál leállítva, mint az adatbázisodat.

Ne állítson mindent -1000-re. Ha semmi sem leállítható, a kernel végül pánikba esik vagy lefagy, ami még rosszabb.

Memória korlátozása cgroups és systemd segítségével

A pontszámok módosítása befolyásolja, hogy ki kerül kikapcsolásra. A cgroups befolyásolja, hogy egyáltalán sor kerül-e globális kikapcsolásra. Ha minden szolgáltatásnak szigorú felső határt ad, a memóriahibákat egyetlen cgroupba tereli, ahelyett, hogy hagyja, hogy egy folyamat kimerítse az egész VPS-t.

Egy systemd egységfájlban:

[Service]
MemoryHigh=400M
MemoryMax=512M
OOMPolicy=stop
Restart=on-failure
RestartSec=5s

MemoryHigh egy puha fojtás: a kernel agresszíven visszanyeri a cgroup ezen pont feletti oldalait, de nem zár le semmit. MemoryMax a kemény felső határ. Ha a cgroup megpróbálja túllépni ezt a határt, a kernel leállít egy folyamatot a cgroupon belül. A Restart=on-failure a szolgáltatás azonnal újraindul.

A cgroup v2-n (Ubuntu 22.04 és újabb, a legújabb Debian, RHEL 9) memory.oom.group minden folyamatot a cgroupon belül egyszerre leállít, ahelyett, hogy árvákat hagyna hátra. Hasznos olyan többfolyamatú szolgáltatásoknál, mint a PHP-FPM poolok, ahol egy félig leállított csoport nem fog megfelelően működni.

Néhány alkalmazás-specifikus megjegyzés, amit érdemes figyelembe venni:

• PHP-FPM: állítsa be pm = ondemand a kis VPS-instanciákon, és a méretet pm.max_children az átlagos munkavállalónkénti RSS-hez, ne az alapértelmezetthez. Egy 2 GB-os VPS-en 4 GB-os tartalékkal méretezett pool az első feltöltődéskor OOM hibát fog okozni.
• Node.js: korlátozza a V8-heapot a --max-old-space-size=512 (MB-ban). Enélkül a Node addig növekszik, amíg a kernel be nem avatkozik.
• MySQL és PostgreSQL: innodb_buffer_pool_size és shared_buffers szabad helyet kell hagyni az operációs rendszer oldalgyorsítótárának, a kapcsolati memóriának és a gépen futó egyéb alkalmazásoknak. Az alapértelmezett értékek dedikált szervert feltételeznek.

A naplófájlok olvasása OOM esemény után

Amikor az OOM killer elindul, a kernel egy részletes jelentést ment a gyűrűpufferbe. Hívja le a következő paranccsal:

dmesg -T | grep -iE 'killed process|out of memory'
journalctl -k --grep='Out of memory'

A figyelmesen elolvasandó blokk az invokátorral kezdődik és az áldozattal végződik. A kernel kinyomtatja a teljes feladatlista minden folyamat RSS-ét, swap-használatát és végső oom_score_adjértékét. Három dolgot érdemes ellenőrizni:

• A korlátozás. CONSTRAINT_NONE globális OOM-ot jelent, CONSTRAINT_MEMCG azt jelenti, hogy egy cgroup elérte a határértékét. A megoldás mindkét esetben más.
• Free swap. Ha ez 0kB, akkor mind a RAM, mind a swap kimerült. Vagy adjon hozzá swap-ot, növelje MemoryMax a problémás folyamatra, vagy csökkentse a párhuzamosságot.
• Az áldozat pontszáma a többihez képest. Ha az áldozat pontszáma nem sokkal magasabb, mint a következő néhány folyamaté, akkor a oom_score_adj értékek nem végeznek elég munkát. Növelje a különbséget.

Kifejezetten a cgroup OOM-ek esetében a kill számláló a memory.events a cgroupon belül:

cat /sys/fs/cgroup/system.slice/mysql.service/memory.events

A növekvő oom_kill szám azt jelenti, hogy a szolgáltatás ismétlődően eléri a határértékét. Ez jelzi, hogy növelni kell MemoryMax, a terhelés profilozására vagy a szolgáltatás áthelyezésére egy nagyobb tervre, nem pedig arra, hogy folyamatosan újraindítsuk.

Összefoglalás

Az OOM killer beállítása nem azt jelenti, hogy eltüntetjük. Arról szól, hogy szabályozzuk, melyik folyamat fizeti meg az árát, amikor elfogy a memória, és csökkentjük a hatást, amikor ez megtörténik. A termelésben érvényesülő minta:

• Védje meg azokat a szolgáltatásokat, amelyek elvesztését nem engedheti meg magának, különösen az sshd-t és az adatbázisokat.
• Minden mást korlátozzon MemoryMax egy systemd egységbe, így egy-egy elszabadult folyamat csak egy újraindítást jelent, nem pedig leállást.
• Figyelje a PSI-t és MemAvailable ahelyett, hogy várnánk dmesg utólag tájékoztasson a helyzetről.
• Hagyjon 15–20 százalékos tartalékot a RAM-ból. A hangolás nem pótolhatja azt, ha a VPS egyszerűen túl kicsi a terheléshez.

Ha a memóriaigénye inkább szerkezeti, mint konfigurálható, akkor több RAM-ra vagy gyorsabb swap-alapú tárolóra van szüksége. Az FDC Servers VPS-csomagjai AMD EPYC processzoron és NVMe-tárolón futnak, ami elég gyorsan tartja a swap-alapú olvasást ahhoz, hogy a rövid memóriaigény-csúcsok ne vezessenek a rendszer leállásához.