A Linux memóriakezelésének magyarázata: swap, OOM killer és cgroups

A Linux másképp kezeli a memóriát, mint a legtöbb operációs rendszer. A magas RAM-használat nem mindig jelent problémát – a kernel aktívan használja a szabad memóriát gyorsítótárként a lemezolvasás felgyorsítására. De amikor valódi memóriaigény keletkezik, három mechanizmus lép működésbe: a swap, az OOM killer és a cgroups. Az egyes mechanizmusok működésének és konfigurálásának megértése jelenti a különbséget egy olyan szerver és egy olyan szerver között, amely terhelés alatt fokozatosan lassul, illetve figyelmeztetés nélkül összeomlik.

Hogyan kezeli a Linux a memóriaoldalakat

Minden folyamat a saját virtuális címterében fut, amely 64 bites rendszereken akár 128 TB is lehet. A kernel ezeket a virtuális címeket oldaltáblák segítségével rendeli hozzá a fizikai RAM-hoz, a Translation Lookaside Buffer (TLB) pedig a legutóbbi kereséseket tárolja a gyorsítótárban. Egy TLB-találat körülbelül 1 nanoszekundumot vesz igénybe; egy elhibázás 20–100 nanoszekundumba kerül, ami memóriát igénylő feladatoknál, például adatbázisoknál, jelentősen megnöveli a terhelést.

A fizikai memória 4 KB-os oldalakra van felosztva, és a kernel két kategóriába sorolja őket:

• Fájlalapú oldalak — a lemezen lévő fájlokhoz kapcsolódnak. A rendszermag a tiszta oldalakat eldobhatja, a piszkosakat pedig kiürítheti anélkül, hogy swap-ra lenne szüksége.
• Névtelen oldalak — háttérfájl nélküli heap- és stack-memória. Ezeket a swapba kell írni, mielőtt a kernel felszabadíthatná őket.

A nagy memóriaigényű szervereken az anonim oldalak nagy aránya azt jelenti, hogy a swap korán bekapcsolódik. Figyelje a si (swap in) és so (swap out) oszlopokat a vmstat 1 — a tartósan nullától eltérő értékek az első figyelmeztetés arra, hogy a rendszer terhelés alatt van.

A figyeléshez használja a feladatra legalkalmasabb eszközt:

Egy gyakori hiba: a free oszlopot free -h és pánikba esni. A available az, ami számít. Ez tartalmazza azt a memóriát is, amelyet a kernel igény szerint visszaszerezhet a gyorsítótárból. Egy szerver, amely csak 512 MB szabad, de 5 GB rendelkezésre álló memóriát jelez, nincs bajban.

Amikor a memória egy küszöbérték alá csökken, a kernel kswapd daemonja elkezdi visszanyerni az oldalakat a háttérben. Ha ez nem elég, a kernel közvetlen visszanyerésre vált, blokkolva a folyamatokat, amíg az oldalak felszabadulnak. Innen származnak a késleltetési csúcsok. Állítson be riasztást, amikor MemAvailable a teljes RAM 10–15%-a alá csökken, így lesz ideje reagálni.

A swap konfigurálása

A swap egy lemezterület – lehet partíció vagy fájl –, ahová a kernel áthelyezi az inaktív névtelen oldalakat, amikor a RAM megtelik. A sebességbeli különbség jelentős: a DDR4 RAM késleltetése körülbelül 100 ns, míg az NVMe SSD-knél ez körülbelül 100 000 ns, a SATA SSD-knél pedig közel 500 000 ns. A swap egy biztonsági puffer, nem pedig extra RAM. Egy olyan szerver, amely folyamatosan a swapra támaszkodik, memóriaproblémával küzd, amit több swap sem fog megoldani.

Használjon swap fájlt partíció helyett. Ez könnyebben átméretezhető, és nem igényel újraparticionálást.

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

Adja hozzá a fájlt /etc/fstab , hogy az újraindítások után is megmaradjon. A chmod 600 lépés szükséges — a RAM-ból kicserélt adatok a swapból olvashatók, ezért a fájl nem lehet mindenki számára olvasható.

A swap létrehozása után állítsa be a vm.swappiness. Az alapértelmezett 60 érték agresszív. A legtöbb tárhely-terhelés esetén célszerű, hogy a kernel a RAM-ot részesítse előnyben, és csak végső esetben használja a swap-ot:

A swap mérete: 1–2 GB elegendő egy 2 GB-os VPS-hez, amely alkalmankénti forgalomcsúcsokat kezel. 8 GB-os vagy annál nagyobb rendszereken általában elegendő egy 2–4 GB-os fix swap. A cél az, hogy a kerneltől egy nyomáscsökkentő szelepet biztosítsunk a hideg oldalak számára, nem pedig a teljes címzett memória kiterjesztése.

A bő CPU-val rendelkező, de RAM-korlátozott szervereken a zram tömörített swap területet hoz létre a memóriában, így teljesen elkerülve a lemez I/O-t. Érdemes megfontolni ezt olyan többbérlős VPS-hostokon, ahol az NVMe-t a bérlők között megosztják. Figyeljen az I/O-versengésre, ha a swap ugyanazon az eszközön található, mint az adatbázis-fájlok — az intenzív swapolás és a nagy átviteli sebességű lemezírás nem jól működik együtt.

Az OOM killer

Amikor a kernel kimeríti a RAM-ot és a swap-ot, és más eszközökkel nem tud elegendő memóriát visszanyerni, az OOM killer lép működésbe. A oom_badness() funkcióval:

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

A legmagasabb pontszámot elért folyamatot leállítja. A képlet a nagy memóriafogyasztókat részesíti előnyben, és a kernel elkerüli a folyamatok gyors egymás utáni leállítását azzal, hogy ellenőrzi, hogy egy folyamatot az elmúlt 5 másodpercben már leállítottak-e.

Kétféle OOM esemény jelenik meg a naplófájlokban:

• Globális OOM — az egész rendszernek elfogyott a RAM-ja és a swap-ja. A naplófájlok előtagja Out of memory:
• Cgroup OOM — egy konténer vagy szolgáltatás elérte a memory.max határát. A naplóbejegyzések előtagja Memory cgroup out of memory:

A korábbi OOM események áttekintéséhez:

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

Figyeljen az order mezőre az OOM naplóban. A 0 feletti érték inkább memóriafragmentációt jelez, mint teljes kimerülést — a kernel nem talált elegendő összefüggő oldalt, még akkor sem, ha szabad memória állt rendelkezésre.

Befolyásolhatja, hogy az OOM-gyilkos mely folyamatokat célozza meg, a /proc/<pid>/oom_score_adj. A tartomány -1000 (soha ne öljön meg) és +1000 (először öljön meg) között van. A systemd által kezelt szolgáltatások esetében állítsa be ezt véglegesen az egységfájlban:

[Service]
OOMScoreAdjust=-1000

További sysctl paraméterek az OOM viselkedésének finomhangolásához:

Proaktív felügyelethez ellenőrizze /proc/pressure/memory (Pressure Stall Information, elérhető a 4.20-as kerneltől kezdve). Figyelje az some avg10 értéket: 5% alatt minden rendben van, a 20% feletti tartós érték pedig azt jelenti, hogy valószínűleg OOM esemény következik be. A növekvő allocstall számláló /proc/vmstat egy másik korai jelzés — ez számolja a közvetlen visszanyerési leállásokat, amelyek gyakran megelőzik az OOM-leállításokat. Az olyan eszközök, mint a systemd-oomd vagy earlyoom működhetnek a PSI küszöbértékek alapján, mielőtt a kernel OOM-killere beindulna.

Cgroups és memóriakorlátok

A vezérlőcsoportok (cgroups) lehetővé teszik a folyamatok csoportokba rendezését és szigorú erőforrás-korlátozások érvényesítését. A Linux 2.6.24-ben bevezetett cgroups a konténer futtatókörnyezetek, köztük a Docker, a Podman, a Kubernetes és az LXC alapját képezik. A kernel nyomon követi a memóriahasználatot cgrouponként, beleértve az anonim memóriát, a fájlokkal támogatott oldalakat és a kernelobjektumokat. Ha egy cgroup eléri a korlátját, a kernel visszanyeri a memóriát az adott csoporton belül, vagy cgroup-szintű OOM kill-t indít.

A cgroup v1 és v2 elsősorban felépítésükben különböznek egymástól. A v1 minden vezérlőt (memória, CPU, I/O) külön csatlakoztat a /sys/fs/cgroup/<controller>/alá, ami következetlen erőforrás-nyomon követéshez vezet. A V2 egységes hierarchiát használ a /sys/fs/cgroup/. A Kubernetes az 1.25-ös verzióban alapértelmezésként áttért a v2-re, és az 1.31-es verzióban megszüntette a v1 támogatását.

A rendszer által használt verzió ellenőrzéséhez:

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

cgroup2fs azt jelenti, hogy v2; tmpfs általában v1-et jelent.

A cgroup v2 legfontosabb memóriavezérlői:

Gyakorlati szabály: állítsa memory.high körülbelül 10–20%-kal alacsonyabbra memory.max , hogy a kernelnak legyen helye visszanyerni a memóriát, mielőtt elérné a kemény korlátot. A méret meghatározásakor memory.max, adjon hozzá 20–30%-ot az alkalmazás csúcsfelhasználása fölé, hogy figyelembe vegye a lapozási gyorsítótárat, amely beleszámít a cgroup memóriájának összmennyiségébe.

A cgroupokat inkább a systemd-n keresztül kezelje, ahelyett, hogy közvetlenül a cgroup fájlrendszerbe írna. Használjon olyan unit fájl utasításokat, mint a MemoryMax=, MemoryHigh=és MemoryMin= az állandó korlátokhoz. Gyors tesztekhez:

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

Webszerver munkavállalói poolok esetében a memory.oom.group=1 beállítása biztosítja a tiszta leállítást, ha egy munkás túllépi a korlátját — nem maradnak hátra árva folyamatok. Adatbázis-motorok esetében a memory.min megvédi a pufferpoolt attól, hogy rendszer szintű terhelés alatt visszakerüljön a rendszerbe.

Memória konfiguráció szerver szerepkör szerint

A megfelelő memóriabeállítások attól függnek, hogy a szerver milyen feladatot lát el. Ha ugyanazt a konfigurációt alkalmazzuk egy adatbázisra és egy PHP webszerverre, az egyikük működését rontja.

MySQL és PostgreSQL esetén a rendelkezésre álló RAM 50–70%-át rendelje hozzá innodb_buffer_pool_size, tiltsa le a Transparent Huge Pages funkciót a késleltetési csúcsok csökkentése érdekében, és védje a folyamatot OOMScoreAdjust=-900 a systemd egységfájlban.

PHP-FPM esetén a munkavállalói poolok méretét a tényleges memóriahasználathoz igazítsa. Minden munkavállaló általában 30–100 MB-ot használ. Ossza el a kiosztott RAM-ot az átlagos munkavállalói mérettel, hogy biztonságos pm.max_children értéket kapjon. Használja a memory.max a cgroups-ban a pool korlátozásához.

Írásintenzív terhelések esetén állítsa be vm.dirty_ratio értéket körülbelül 10%-ra, a vm.dirty_background_ratio értéket 3%-ra. Ez gyakrabban üríti ki a piszkos oldalakat, elkerülve a nagy I/O-leállásokat.

A paraméterek /etc/sysctl.d/90-memory.conf. A futásidőben alkalmazott beállítások újraindításkor elvesznek.

A szerepkörök szerinti ajánlott értékek összefoglalása:

Ha nagy sűrűségű munkaterheléseket futtat, és olyan szerverre van szüksége, amely elegendő kapacitással rendelkezik ezeknek a szabályoknak a megfelelő alkalmazásához, érdemes megnéznie az FDC dedikált szervereit.