Vysvětlení správy paměti v Linuxu: swap, OOM killer a cgroups

Linux zachází s pamětí jinak než většina operačních systémů. Vysoké využití RAM není vždy problém – jádro aktivně využívá volnou paměť pro ukládání do mezipaměti, aby urychlilo čtení z disku. Když však dojde k reálnému přetížení paměti, do akce vstupují tři mechanismy: swap, OOM killer a cgroups. Pochopení toho, jak se každý z nich chová a jak je nakonfigurovat, je rozdílem mezi serverem, který se pod zátěží chová elegantně, a serverem, který bez varování havaruje.

Jak Linux spravuje paměťové stránky

Každý proces běží ve svém vlastním virtuálním adresním prostoru, který na 64bitových systémech dosahuje až 128 TB. Jádro mapuje tyto virtuální adresy do fyzické RAM prostřednictvím stránkovacích tabulek, přičemž Translation Lookaside Buffer (TLB) ukládá do mezipaměti nedávné vyhledávání. Zásah TLB trvá přibližně 1 nanosekundu; neúspěch stojí 20–100 nanosekund, což se sčítá u úloh náročných na paměť, jako jsou databáze.

Fyzická paměť je rozdělena na 4 KB stránky a jádro je rozděluje do dvou kategorií:

• Stránky podložené soubory — vázané na soubory na disku. Jádro může vyčistit čisté stránky nebo vyprázdnit špinavé stránky bez nutnosti použití odkládacího prostoru.
• Anonymní stránky – paměť haldy a zásobníku bez podpůrného souboru. Tyto stránky musí být zapsány do odkládací paměti, než je jádro může uvolnit.

Na serverech s vysokými nároky na paměť znamená velký podíl anonymních stránek, že se swap zapojí brzy. Sledujte si (swap in) a so (swap out) v vmstat 1 — trvalé hodnoty odlišné od nuly jsou prvním varováním, že systém je pod tlakem.

Pro monitorování použijte správný nástroj:

Jedna častá chyba: sledování free sloupce free -h a propadání se do paniky. available sloupec je to, na čem záleží. Zahrnuje paměť, kterou jádro může na požádání uvolnit z cache. Server, který ukazuje pouze 512 MB volné paměti, ale 5 GB dostupné, není v potížích.

Když paměť klesne pod prahovou hodnotu, démon kswapd začne na pozadí uvolňovat stránky. Pokud to nestačí, přejde jádro k přímému uvolňování a blokuje procesy, dokud nejsou stránky uvolněny. Odtud pocházejí špičky latence. Nastavte si upozornění, když MemAvailable klesne pod 10–15 % celkové RAM, abyste měli čas reagovat.

Konfigurace swapu

Swap je oblast na disku – buď oddíl, nebo soubor –, kam jádro přesouvá neaktivní anonymní stránky, když se zaplní RAM. Rozdíl v rychlosti je značný: RAM DDR4 má latenci přibližně 100 ns, zatímco SSD NVMe mají latenci kolem 100 000 ns a SSD SATA se blíží 500 000 ns. Swap je bezpečnostní vyrovnávací paměť, nikoli další RAM. Server, který se neustále spoléhá na swap, má problém s pamětí, který více swapu nevyřeší.

Používejte spíše swapový soubor než oddíl. Je snazší změnit jeho velikost a nevyžaduje to přepartitionování.

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

Přidejte soubor tak, /etc/fstab , aby přetrval i po restartu. chmod 600 krok je nutný – jakákoli data vypsaná z RAM jsou čitelná ze swapu, takže soubor nesmí být čitelný pro všechny.

Po vytvoření swapu nastavte vm.swappiness. Výchozí hodnota 60 je agresivní. Pro většinu hostingových úloh je žádoucí, aby jádro upřednostňovalo RAM a swap používalo pouze jako poslední možnost:

Pro velikost swapového prostoru: 1–2 GB stačí pro 2 GB VPS, který zvládá občasné špičky v provozu. Na systémech s 8 GB nebo více je obecně dostačující pevně nastavený swapový prostor o velikosti 2–4 GB. Cílem je poskytnout jádru pojistný ventil pro neaktivní stránky, nikoli rozšířit celkovou adresovatelnou paměť.

Na serverech s omezenou RAM a dostatečným výkonem CPU vytvoří zram komprimovanou swapovou oblast v paměti, čímž zcela eliminuje diskové I/O. Stojí za zvážení na multi-tenantních VPS hostech, kde je NVMe sdíleno mezi nájemci. Dávejte pozor na I/O konflikty, pokud je swap na stejném zařízení jako databázové soubory — intenzivní swapování a vysoký průchod diskových zápisů spolu dobře nesouvisí.

OOM killer

Když jádro vyčerpá RAM a swap a nemůže získat zpět dostatek paměti jinými prostředky, zasáhne OOM killer. Hodnotí procesy pomocí funkce oom_badness() funkce:

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

Proces s nejvyšším skóre je ukončen. Vzorec upřednostňuje procesy s velkou spotřebou paměti a jádro se vyhýbá ukončování více procesů v rychlém sledu tím, že kontroluje, zda byl daný proces ukončen v posledních 5 sekundách.

V protokolech se objevují dva typy událostí OOM:

• Global OOM — celému systému došla RAM i swap. Protokoly začínají předponou Out of memory:
• Cgroup OOM — kontejner nebo služba dosáhla svého memory.max limit. Protokoly začínají předponou Memory cgroup out of memory:

Chcete-li zkontrolovat minulé události OOM:

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

Věnujte pozornost order poli v protokolech OOM. Hodnota vyšší než 0 naznačuje spíše fragmentaci paměti než její úplné vyčerpání — jádro nemohlo najít dostatek souvislých stránek, i když byla k dispozici volná paměť.

Můžete ovlivnit, na které procesy se OOM killer zaměří, úpravou /proc/<pid>/oom_score_adj. Rozsah je od -1000 (nikdy nezabíjet) do +1000 (zabít jako první). U služeb spravovaných systémem systemd nastavte tuto hodnotu trvale v souboru jednotky:

[Service]
OOMScoreAdjust=-1000

Další parametry sysctl pro ladění chování OOM:

Pro proaktivní monitorování zkontrolujte /proc/pressure/memory (Pressure Stall Information, dostupné od jádra 4.20). Sledujte some avg10 hodnotu: pod 5 % je vše v pořádku, trvalá hodnota nad 20 % znamená, že se pravděpodobně blíží událost OOM. Rostoucí allocstall počet v /proc/vmstat je dalším včasným signálem — počítá přímé zastavení při uvolňování paměti, které často předchází ukončení procesů kvůli OOM. Nástroje jako systemd-oomd nebo earlyoom mohou reagovat na prahové hodnoty PSI ještě předtím, než se spustí OOM killer jádra.

Cgroups a limity paměti

Kontrolní skupiny (cgroups) vám umožňují organizovat procesy do skupin a vynucovat přísná omezení zdrojů. Byly zavedeny v Linuxu 2.6.24 a tvoří základ runtime kontejnerů, včetně Dockeru, Podmanu, Kubernetes a LXC. Jádro sleduje využití paměti pro každou cgroup, včetně anonymní paměti, stránek podložených soubory a objektů jádra. Pokud cgroup dosáhne svého limitu, jádro uvolní paměť v rámci této skupiny nebo spustí OOM kill v rozsahu cgroup.

Cgroup v1 a v2 se liší především ve své struktuře. V1 připojuje každý řadič (paměť, CPU, I/O) samostatně pod /sys/fs/cgroup/<controller>/, což vede k nekonzistentnímu sledování zdrojů. V2 používá sjednocenou hierarchii na úrovni /sys/fs/cgroup/. Kubernetes přešel na v2 jako výchozí ve verzi 1.25 a podporu v1 ukončil ve verzi 1.31.

Chcete-li zkontrolovat, kterou verzi váš systém používá:

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

cgroup2fs znamená v2; tmpfs obvykle znamená v1.

Klíčové ovládací prvky paměti v cgroup v2:

Praktické pravidlo: nastavte memory.high asi o 10–20 % méně memory.max , aby jádro mělo prostor pro uvolnění paměti před dosažením pevného limitu. Při dimenzování memory.max, přidejte 20–30 % nad špičkovou spotřebu aplikace, abyste zohlednili stránkovací cache, která se započítává do celkové paměti cgroup.

Spravujte cgroups prostřednictvím systemd namísto přímého zápisu do souborového systému cgroup. Používejte direktivy v souborech jednotek, jako je MemoryMax=, MemoryHigh=a MemoryMin= pro trvalé limity. Pro rychlé testy:

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

Pro skupiny pracovníků webového serveru nastavení memory.oom.group=1 zajišťuje čisté ukončení, pokud jeden pracovník překročí svůj limit — nezůstanou žádné osamocené procesy. U databázových strojů memory.min chrání buffer pool před uvolněním v případě systémového přetížení.

Konfigurace paměti podle role serveru

Správné nastavení paměti závisí na tom, co server dělá. Použití stejné konfigurace pro databázi a webový server PHP poškodí jeden z nich.

Pro MySQL a PostgreSQL alokujte 50–70 % dostupné RAM pro innodb_buffer_pool_size, deaktivujte Transparent Huge Pages, abyste snížili špičky latence, a chraňte proces pomocí OOMScoreAdjust=-900 v souboru jednotky systemd.

U PHP-FPM dimenzujte pracovní skupiny podle skutečného využití paměti. Každý pracovník obvykle spotřebuje 30–100 MB. Vydělte přidělenou RAM průměrnou velikostí pracovníka, abyste získali bezpečnou pm.max_children hodnotu. Použijte memory.max v cgroups k omezení velikosti fondu.

U úloh s intenzivním zápisem nastavte vm.dirty_ratio na přibližně 10 % a vm.dirty_background_ratio na 3 %. Tím se častěji vyprázdní špinavé stránky, čímž se zabrání velkým zpožděním I/O.

Zajistěte trvalé nastavení jádra uložením parametrů do /etc/sysctl.d/90-memory.conf. Nastavení aplikovaná za běhu se při restartu ztratí.

Souhrn doporučených hodnot podle role:

Pokud provozujete vysoce náročné úlohy a potřebujete server s dostatečnou rezervou pro správné uplatnění těchto zásad, stojí za to se podívat na dedikované servery společnosti FDC.