Nastavení Linux OOM killer pro VPS

Linux OOM killer je poslední možnost jádra, když dojde paměť: vybere proces a ukončí ho, aby udržel systém v chodu. Na VPS, kde je RAM omezená a není kam se uchýlit, je výchozí volba často špatná. Vaše databáze je ukončena, dlouhodobě běžící pracovní proces přežije a vy musíte přijít na to, proč. Tento průvodce popisuje, jak OOM killer hodnotí procesy, jak toto hodnocení upřednostnit ve prospěch vašich kritických služeb a jak používat cgroups, aby jeden neovladatelný proces nemohl s sebou strhnout zbytek systému.

Jak si OOM killer vybírá oběť

Když jádro nemůže uvolnit dostatek paměti prostřednictvím vyřazení z stránkovací cache nebo swapování, vyvolá OOM killer. Každý proces má oom_score hodnotu mezi 0 a 1000, odvozenou převážně z jeho velikosti rezidentní sady (RSS) a využití swapového prostoru. Proces s nejvyšším skóre obdrží signál SIGKILL.

RSS dominuje výpočtu, a proto se zabití téměř vždy týká největšího spotřebitele paměti. Často se jedná o vaši databázi, aplikační server nebo jakýkoli dlouhodobý proces, který vykonává nejužitečnější práci. Proces, který alokaci skutečně spustil, „invoker“, je zřídka tím, který je ukončen.

Existují dva typy událostí OOM, které je třeba rozlišovat:

• Globální OOM: hostiteli (nebo vašemu VPS jako celku) došla RAM a swap. Jádro prohledá všechny procesy a ukončí ten s nejvyšším skóre.
• Cgroup OOM: konkrétní cgroup dosáhla svého limitu paměti. Jádro ukončí pouze procesy uvnitř této cgroup, i když zbytek systému má paměť k dispozici.

Pokud jste nakonfigurovali limity jednotek systemd nebo provozujete kontejnery, většina vašich událostí OOM bude typu cgroup OOM. To je dobře: dosah dopadu je omezen.

Zjištění přetížení paměti před selháním

Události OOM nejsou téměř nikdy náhlé. Obvykle se nejprve objeví období rostoucího tlaku a cílem monitorování je zachytit jej právě v tomto období.

free -h vám poskytne přehled o systému. Důležitý je sloupec available, nikoli free: ten představuje uvolnitelnou stránkovací paměť a odráží to, co můžete skutečně alokovat bez swappingu. Udržujte MemAvailable nad přibližně 10 až 15 procent MemTotal při špičkovém zatížení.

Pro přiřazení podle procesu seřaďte podle RSS:

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

Nebo použijte htop a seřaďte podle RES. Hodnoty, které zde vidíte, se přímo promítají do skórování jádra, takže položky na vrcholu seznamu jsou nejpravděpodobnějšími cíli OOM.

U jader 4.20 a novějších je Pressure Stall Information systémem včasného varování, který stojí za to zapojit do monitorování:

cat /proc/pressure/memory

Číslo some avg10 číslo udává procentuální podíl času, po který alespoň jedna úloha v posledních deseti sekundách čekala na paměť. Hodnota pod 5 procent je v pořádku. Trvalé hodnoty nad 10 procent znamenají, že systém tráví reálný čas zablokován při uvolňování paměti a je pravděpodobné, že dojde k ukončení úlohy kvůli nedostatku paměti (OOM).

Swap thrashing se zobrazuje v vmstat 1 jako nenulové si a so sloupcích, které přetrvávají v čase. Malé množství rezidentního swapování je neškodné. Neustálé swapování dovnitř a ven však ne.

Ochrana kritických procesů pomocí oom_score_adj

Skóre, které jádro vypočítává, lze pro každý proces upravit pomocí oom_score_adj, na škále od -1000 (imunní) do +1000 (zabij mě jako první). Úprava se přičítá přímo k finálnímu skóre.

Pro jednorázovou změnu u běžícího procesu:

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

Pro cokoli, co chcete zachovat i po restartu, nastavte to v jednotce systemd. To je správné místo pro sshd, vaši databázi a cokoli jiného, co si nemůžete dovolit ztratit:

[Service]
OOMScoreAdjust=-900

Rozumná výchozí nastavení:

• sshd: -1000. Pokud ztratíte vzdálený přístup během krize paměti, obnovení bude mnohem obtížnější.
• MySQL, PostgreSQL, Redis: -800 až -900. Silná ochrana, aniž by se staly zcela nedotknutelnými v opravdu katastrofické situaci.
• Pracovníci aplikací, dávkové úlohy, cron úlohy: +100 až +500. Jedná se o procesy, u kterých raději uvidíte, že byly ukončeny, než aby došlo k výpadku databáze.

Nenastavujte vše na -1000. Pokud nelze nic ukončit, jádro nakonec místo toho zpanikaří nebo zamrzne, což je ještě horší.

Omezení paměti pomocí cgroups a systemd

Úprava skóre ovlivňuje, kdo bude ukončen. Cgroups ovlivňují, zda k globálnímu ukončení vůbec dojde. Tím, že každé službě přidělíte pevnou horní hranici, přesunete selhání paměti do jedné cgroup, místo aby jeden proces vyčerpal celý VPS.

V souboru jednotky systemd:

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

MemoryHigh je měkké omezení: jádro agresivně získává zpět stránky z cgroup nad tímto bodem, ale nic neukončuje. MemoryMax je pevný strop. Pokud se cgroup pokusí alokovat více, jádro ukončí proces uvnitř cgroup. S Restart=on-failure se služba okamžitě znovu spustí.

Na cgroup v2 (Ubuntu 22.04 a novější, nejnovější Debian, RHEL 9) memory.oom.group ukončí všechny procesy v cgroup najednou, místo aby zanechával osamocené procesy. To je užitečné pro služby s více procesy, jako jsou skupiny PHP-FPM, kde by částečně ukončená skupina fungovala nesprávně.

Několik poznámek specifických pro danou aplikaci, které stojí za to uplatnit:

• PHP-FPM: nastavte pm = ondemand na malých instancích VPS a velikost pm.max_children vzhledem k průměrné velikosti RSS na pracovníka, nikoli k výchozí hodnotě. Pool dimenzovaný na 4 GB volné paměti na 2 GB VPS vyčerpá paměť (OOM) hned při prvním naplnění.
• Node.js: omezte V8 heap pomocí --max-old-space-size=512 (v MB). Bez toho bude Node vesele růst, dokud nezasáhne jádro.
• MySQL a PostgreSQL: innodb_buffer_pool_size a shared_buffers by měly ponechat volnou rezervu pro stránkovací cache operačního systému, paměť pro připojení a jakékoli další nájemce na stroji. Výchozí nastavení předpokládá dedikovaný server.

Čtení protokolů po události OOM

Když se spustí OOM killer, jádro vypíše podrobnou zprávu do kruhového bufferu. Získejte ji pomocí:

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

Blok, který je třeba pečlivě přečíst, začíná volajícím a končí obětí. Jádro vypíše úplný seznam úloh s RSS každého procesu, využitím swapového prostoru a konečným oom_score_adj. Stojí za to zkontrolovat tři věci:

• Omezení. CONSTRAINT_NONE znamená globální OOM, CONSTRAINT_MEMCG znamená, že cgroup dosáhla svého limitu. Řešení se v každém případě liší.
• Free swap. Pokud se jedná o 0kB, vyčerpala se jak RAM, tak swap. Buď přidejte swap, zvyšte MemoryMax výkon procesu, který to způsobuje, nebo omezte souběžnost.
• Skóre oběti ve srovnání se vším ostatním. Pokud skóre oběti není o moc vyšší než u několika následujících procesů, vaše oom_score_adj hodnoty nefungují dostatečně. Zvětšete rozdíl.

Konkrétně u OOM v cgroup se počítadlo kill nachází memory.events uvnitř cgroup:

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

Rostoucí oom_kill počtu znamená, že služba opakovaně naráží na svůj limit. To je signál ke zvýšení MemoryMax, analyzovat pracovní zátěž nebo přesunout službu na větší plán, a ne ji neustále restartovat v nekonečné smyčce.

Závěr

Nastavení OOM killeru nespočívá v tom, aby zmizel. Jde o to, kontrolovat, který proces zaplatí cenu, když dojde paměť, a zmenšit rozsah dopadu, když k tomu dojde. Vzor, který platí v produkčním prostředí:

• Chraňte služby, o které si nemůžete dovolit přijít, zejména sshd a vaše databáze.
• Vše ostatní omezte pomocí MemoryMax v jednotce systemd, aby jeden neovladatelný proces znamenal pouze restart, nikoli výpadek.
• Sledujte PSI a MemAvailable místo toho, abyste čekali na dmesg , až vám to řeknou až poté.
• Nechte si 15 až 20 procent RAM jako rezervu. Ladění nemůže kompenzovat VPS, který je pro danou zátěž prostě příliš malý.

Pokud je váš tlak na paměť spíše strukturální než konfigurovatelný, potřebujete více RAM nebo rychlejší úložiště podporované swapem. Plány VPS od FDC Servers běží na AMD EPYC s úložištěm NVMe, což udržuje čtení podporované swapem dostatečně rychlé, aby krátké výkyvy paměti neeskalovaly do ukončení.