Linux minneshantering förklarat: swap, OOM killer och cgroups

Linux hanterar minne på ett annat sätt än de flesta operativsystem. Hög RAM-användning är inte alltid ett problem – kärnan använder aktivt ledigt minne för caching för att påskynda diskavläsningar. Men när det uppstår verklig minnesbelastning träder tre mekanismer i funktion: swap, OOM killer och cgroups. Att förstå hur var och en av dem fungerar och hur man konfigurerar dem är skillnaden mellan en server som hanterar belastning på ett smidigt sätt och en som kraschar utan förvarning.

Hur Linux hanterar minnessidor

Varje process körs i sitt eget virtuella adressutrymme, upp till 128 TB på 64-bitars system. Kärnan mappar dessa virtuella adresser till fysiskt RAM-minne genom sidtabeller, där Translation Lookaside Buffer (TLB) cachelagrar de senaste sökningarna. En TLB-träff tar cirka 1 nanosekund; en miss kostar 20–100 nanosekunder, vilket summeras i minnesintensiva arbetsbelastningar som databaser.

Det fysiska minnet är uppdelat i sidor på 4 KB, och kärnan delar upp dem i två kategorier:

• Filbaserade sidor – kopplade till filer på disken. Kärnan kan kasta bort rena sidor eller tömma smutsiga sidor utan att behöva använda swap.
• Anonyma sidor – heap- och stackminne utan bakomliggande fil. Dessa måste skrivas till swap innan kärnan kan frigöra dem.

På servrar med högt minnesbehov innebär en stor andel anonyma sidor att swap involveras tidigt. Håll koll på si (swap in) och so (swap ut) i vmstat 1 — bestående värden som inte är noll är din första varning om att systemet är under press.

Använd rätt verktyg för övervakning:

Ett vanligt misstag: att titta på free kolumnen i free -h och drabbas av panik. Det är kolumnen available kolumnen är det som spelar roll. Den inkluderar minne som kärnan kan återvinna från cachen vid behov. En server som endast visar 512 MB ledigt men 5 GB tillgängligt är inte i trubbel.

När minnet sjunker under en tröskel börjar kärnans kswapd demon att återvinna sidor i bakgrunden. Om det inte räcker övergår kärnan till direkt återvinning och blockerar processer tills sidorna frigörs. Det är här latensspikarna kommer ifrån. Ställ in en varning när MemAvailable faller under 10–15 % av det totala RAM-minnet så att du hinner reagera.

Konfigurera swap

Swap är ett diskutrymme – antingen en partition eller en fil – dit kärnan flyttar inaktiva anonyma sidor när RAM-minnet blir fullt. Hastighetsskillnaden är betydande: DDR4-RAM har ungefär 100 ns latens, medan NVMe-SSD:er ligger runt 100 000 ns och SATA-SSD:er närmare 500 000 ns. Swap är en säkerhetsbuffert, inte extra RAM. En server som konsekvent förlitar sig på swap har ett minnesproblem som inte kan lösas med mer swap.

Använd en swap-fil istället för en partition. Det är enklare att ändra storlek och kräver ingen ompartitionering.

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

Lägg till filen /etc/fstab för att behålla den vid omstart. chmod 600 steget krävs – alla data som pagineras ut från RAM-minnet är läsbara från swap, så filen får inte vara läsbar för alla.

Efter att ha skapat swap, justera vm.swappiness. Standardvärdet 60 är aggressivt. För de flesta värdbelastningar vill du att kärnan ska prioritera RAM-minnet och endast använda swap som en sista utväg:

För swap-storlek: 1–2 GB räcker för en 2 GB VPS som hanterar tillfälliga trafiktoppar. På system med 8 GB eller mer är en fast swap på 2–4 GB i allmänhet tillräcklig. Målet är att ge kärnan en tryckventil för kalla sidor, inte att utöka det totala adresserbara minnet.

På servrar med begränsat RAM-minne men gott om CPU-kapacitet skapar zram ett komprimerat swap-område i minnet, vilket helt undviker disk-I/O. Det är värt att överväga på VPS-värdar med flera hyresgäster där NVMe delas mellan hyresgästerna. Se upp för I/O-konflikter om swap-utrymmet finns på samma enhet som databasfilerna – tung swap-användning och disk-skrivningar med hög genomströmning fungerar inte bra tillsammans.

OOM-killer

När kärnan har förbrukat RAM-minnet och swap-utrymmet och inte kan återvinna tillräckligt med minne på annat sätt, träder OOM-killer in. Den poängsätter processer med hjälp av oom_badness() funktionen:

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

Processen med högst poäng avslutas. Formeln gynnar processer som förbrukar mycket minne, och kärnan undviker att avsluta flera processer i snabb följd genom att kontrollera om en process redan har avslutats under de senaste 5 sekunderna.

Två typer av OOM-händelser visas i loggarna:

• Global OOM — hela systemet har slut på RAM och swap. Loggarna har prefixet Out of memory:
• Cgroup OOM — en container eller tjänst har nått sin memory.max gräns. Loggarna har prefixet Memory cgroup out of memory:

Så här granskar du tidigare OOM-händelser:

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

Var uppmärksam på order fältet i OOM-loggarna. Ett värde över 0 tyder på minnesfragmentering snarare än total uttömning — kärnan kunde inte hitta tillräckligt med sammanhängande sidor trots att det fanns ledigt minne tillgängligt.

Du kan påverka vilka processer OOM-killer riktar in sig på genom att justera /proc/<pid>/oom_score_adj. Intervallet är -1000 (avsluta aldrig) till +1000 (avsluta först). För systemd-hanterade tjänster ställer du in detta permanent i enhetsfilen:

[Service]
OOMScoreAdjust=-1000

Ytterligare sysctl-parametrar för att justera OOM-beteendet:

För proaktiv övervakning, kontrollera /proc/pressure/memory (Pressure Stall Information, tillgängligt sedan kärna 4.20). Håll koll på some avg10 värdet: under 5 % är normalt, om det ligger kvar över 20 % innebär det att en OOM-händelse troligen är på väg. En stigande allocstall räknare i /proc/vmstat är en annan tidig signal — den räknar direkta återvinningsstopp, som ofta föregår OOM-avslutningar. Verktyg som systemd-oomd eller earlyoom kan agera på PSI-trösklar innan kärnans OOM-killer aktiveras.

Cgroups och minnesgränser

Kontrollgrupper (cgroups) låter dig organisera processer i grupper och tillämpa hårda resursbegränsningar. De introducerades i Linux 2.6.24 och utgör grunden för container-runtimes, inklusive Docker, Podman, Kubernetes och LXC. Kärnan spårar minnesanvändningen per cgroup, vilket omfattar anonymt minne, filbaserade sidor och kärnobjekt. Om en cgroup når sin gräns återvinner kärnan minne inom den gruppen eller utlöser en OOM-avstängning inom cgroup-området.

Cgroup v1 och v2 skiljer sig främst åt i hur de är strukturerade. V1 monterar varje kontroller (minne, CPU, I/O) separat under /sys/fs/cgroup/<controller>/, vilket leder till inkonsekvent resursspårning. V2 använder en enhetlig hierarki vid /sys/fs/cgroup/. Kubernetes bytte till v2 som standard i version 1.25 och tog bort stödet för v1 i 1.31.

För att kontrollera vilken version ditt system använder:

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

cgroup2fs betyder v2; tmpfs betyder vanligtvis v1.

De viktigaste minneskontrollerna i cgroup v2:

En praktisk regel: ställ in memory.high cirka 10–20 % lägre memory.max för att ge kärnan utrymme att återvinna innan den når den hårda gränsen. När du dimensionerar memory.max, lägg till 20–30 % utöver applikationens högsta användning för att ta hänsyn till sidcache, som räknas in i cgroups totala minne.

Hantera cgroups via systemd istället för att skriva direkt till cgroups filsystem. Använd direktiv i enhetsfiler som MemoryMax=, MemoryHigh=, och MemoryMin= för beständiga gränser. För snabba tester:

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

För webbserverns arbetspooler säkerställer inställningen memory.oom.group=1 säkerställer en ren avslutning om en arbetare överskrider sin gräns — inga övergivna processer lämnas kvar. För databasmotorer memory.min skyddar buffertpoolen från att återvinnas under systemomfattande belastning.

Minnekonfiguration efter serverroll

Rätt minnesinställningar beror på vad servern gör. Att använda samma konfiguration för en databas och en PHP-webbserver kommer att skada en av dem.

För MySQL och PostgreSQL, allokera 50–70 % av tillgängligt RAM-minne till innodb_buffer_pool_size, inaktivera Transparent Huge Pages för att minska latensspikar och skydda processen med OOMScoreAdjust=-900 i systemd-enhetsfilen.

För PHP-FPM, dimensionera arbetarpoolerna efter faktisk minnesanvändning. Varje arbetare använder vanligtvis 30–100 MB. Dela det tilldelade RAM-minnet med den genomsnittliga arbetarstorleken för att få ett säkert pm.max_children värde. Använd memory.max i cgroups för att begränsa poolen.

För skrivintensiva arbetsbelastningar, ställ in vm.dirty_ratio till cirka 10 % och vm.dirty_background_ratio till 3 %. Detta tömmer smutsiga sidor oftare, vilket undviker stora I/O-stopp.

Gör kärnoptimeringen bestående genom att spara parametrarna i /etc/sysctl.d/90-memory.conf. Inställningar som tillämpas under körning går förlorade vid omstart.

För en sammanfattning av rekommenderade värden per roll:

Om du kör arbetsbelastningar med hög densitet och behöver en server med tillräcklig kapacitet för att tillämpa dessa policyer på rätt sätt, är FDC:s dedikerade servrar värda att titta närmare på.