Linux OOM killer-inställningar för VPS

Linux OOM killer är kärnans sista utväg när minnet tar slut: den väljer ut en process och avslutar den för att hålla systemet igång. På en VPS, där RAM-minnet är begränsat och det inte finns någon reserv, är standardvalet ofta fel. Din databas avslutas, en långvarig process överlever, och du får själv lista ut varför. Denna guide beskriver hur OOM-killer poängsätter processer, hur du kan styra poängsättningen mot dina kritiska tjänster och hur du använder cgroups så att en enskild process som går amok inte kan dra ner resten av systemet med sig.

Hur OOM-killer väljer ett offer

När kärnan inte kan återvinna tillräckligt med minne genom att rensa sidcachen eller använda swap, aktiverar den OOM-killer. Varje process har ett oom_score mellan 0 och 1000, som främst härleds från dess Resident Set Size (RSS) och swap-användning. Processen med den högsta poängen får ett SIGKILL.

RSS dominerar beräkningen, vilket är anledningen till att avslutningen nästan alltid drabbar den som förbrukar mest minne. Det är ofta din databas, din applikationsserver eller vilken långlivad process som helst som utför det mest användbara arbetet. Den process som faktiskt utlöste allokeringen, ”invokern”, är sällan den som avslutas.

Det finns två typer av OOM-händelser som du måste hålla isär:

• Global OOM: värden (eller din VPS som helhet) har slut på RAM och swap. Kärnan skannar varje process och avslutar den med högst poäng.
• Cgroup OOM: en specifik cgroup har nått sin minnesgräns. Kärnan avslutar endast processer inom den cgroupen, även om resten av systemet har minne över.

Om du har konfigurerat systemd-enhetsgränser eller kör containrar kommer de flesta av dina OOM-händelser att vara cgroup OOM. Det är bra: skadeområdet begränsas.

Upptäcka minnesbelastning innan systemet kraschar

OOM-händelser inträffar nästan aldrig plötsligt. Det finns vanligtvis ett fönster med växande belastning först, och målet med övervakningen är att upptäcka det inom det fönstret.

free -h ger dig systemvyn. Den kolumn som är viktig är available, inte free: den står för återvinningsbar sidcache och speglar vad du faktiskt kan allokera utan att byta ut. Håll MemAvailable över ungefär 10 till 15 procent av MemTotal vid toppbelastning.

För tilldelning per process, sortera efter RSS:

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

Eller använd htop och sortera efter RES. Värdena du ser här matas direkt in i kärnans poängsättning, så de översta posterna är de mest troliga OOM-målen.

I kärnor 4.20 och senare är Pressure Stall Information det tidiga varningssystem som är värt att koppla in i övervakningen:

cat /proc/pressure/memory

Siffran some avg10 siffran är den procentuella andelen tid som minst en uppgift har fastnat i väntan på minne under de senaste tio sekunderna. Under 5 procent är det bra. Kontinuerliga värden över 10 procent innebär att systemet spenderar reell tid blockerat på minnesåtervinning, och en OOM-avstängning är trolig.

Swap thrashing visas i vmstat 1 som icke-noll si och so kolumner som kvarstår över tid. En liten mängd resident swap är ofarligt. Konstant swap-in och swap-out är det inte.

Skydda kritiska processer med oom_score_adj

Det värde som kärnan beräknar kan justeras per process genom oom_score_adj, på en skala från -1000 (immun) till +1000 (döda mig först). Justeringen läggs direkt till det slutliga poängtalet.

För en engångsändring mot en pågående process:

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

För allt du vill ska bestå över omstarter, ställ in det i systemd-enheten. Det är rätt plats för sshd, din databas och allt annat du inte har råd att förlora:

[Service]
OOMScoreAdjust=-900

Förnuftiga standardvärden att utgå ifrån:

• sshd: -1000. Om du förlorar fjärråtkomst under en minneskris blir återställningen mycket svårare.
• MySQL, PostgreSQL, Redis: -800 till -900. Starkt skydd utan att göra dem helt oåtkomliga i en verkligt katastrofal situation.
• Applikationsarbetare, batchjobb, cron-uppgifter: +100 till +500. Det här är processer som du hellre ser dödas än din databas.

Ställ inte in allt på -1000. Om ingenting kan avslutas kommer kärnan så småningom att gå i panik eller frysa istället, vilket är värre.

Begränsa minnet med cgroups och systemd

Justering av poäng påverkar vem som avslutas. Cgroups påverkar om den globala avslutningen någonsin sker. Genom att ge varje tjänst en fast övre gräns förflyttar du minnesfel till en enda cgroup istället för att låta en process tömma hela VPS:en.

I en systemd-enhetsfil:

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

MemoryHigh är en mjuk strypning: kärnan återtar aggressivt sidor från cgruppen ovanför denna punkt men avslutar ingenting. MemoryMax är den hårda gränsen. Om cgruppen försöker allokera utöver den, avslutar kärnan en process inuti cgruppen. Med Restart=on-failure kommer tjänsten direkt tillbaka.

På cgroup v2 (Ubuntu 22.04 och senare, nyare Debian, RHEL 9), memory.oom.group avslutas alla processer i cgruppen samtidigt istället för att lämna kvar övergivna processer. Användbart för tjänster med flera processer som PHP-FPM-pooler där en halvavslutad grupp kommer att fungera felaktigt.

Några applikationsspecifika anmärkningar som är värda att tillämpa:

• PHP-FPM: ställ in pm = ondemand på små VPS-instanser och storlek pm.max_children mot genomsnittlig RSS per arbetare, inte standardvärdet. En pool dimensionerad för 4 GB utrymme på en 2 GB VPS kommer att få OOM-fel första gången den fylls.
• Node.js: begränsa V8-heapen med --max-old-space-size=512 (i MB). Utan detta kommer Node att växa obehindrat tills kärnan ingriper.
• MySQL och PostgreSQL: innodb_buffer_pool_size och shared_buffers bör lämna tydligt utrymme för OS-sidcachen, anslutningsminnet och eventuella andra användare på servern. Standardinställningarna utgår från en dedikerad server.

Läsa loggarna efter en OOM-händelse

När OOM-killer aktiveras dumpar kärnan en detaljerad rapport till ringbufferten. Hämta den med:

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

Det block som ska läsas noggrant börjar med den som anropade och slutar med offret. Kärnan skriver ut en fullständig uppgiftslista med varje process RSS, swap-användning och slutlig oom_score_adj. Tre saker är värda att kontrollera:

• Begränsningen. CONSTRAINT_NONE betyder en global OOM, CONSTRAINT_MEMCG betyder att en cgroup har nått sin gräns. Lösningen är olika i varje fall.
• Free swap. Om detta är 0kB, har både RAM och swap uttömts. Antingen lägg till swap, höj MemoryMax på den skyldige eller minska samtidigheten.
• Offrets poäng jämfört med allt annat. Om offrets poäng inte är mycket högre än de närmast följande processerna, gör dina oom_score_adj värden inte gör tillräckligt. Öka skillnaden.

Specifikt för cgroup-OOM:er finns kill-räknaren memory.events inuti cgruppen:

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

En stigande oom_kill antal innebär att tjänsten upprepade gånger når sin gräns. Det är en signal att höja MemoryMax, profilera arbetsbelastningen eller flytta tjänsten till en större plan, inte att fortsätta starta om den i en loop.

Sammanfattning

Att justera OOM-killer handlar inte om att få den att försvinna. Det handlar om att kontrollera vilken process som får betala priset när minnet tar slut, och att minska skadeomfånget när det händer. Det mönster som gäller i produktion:

• Skydda de tjänster du inte har råd att förlora, särskilt sshd och dina databaser.
• Begränsa allt annat med MemoryMax i en systemd-enhet så att en enskild process som går amok innebär en enkel omstart, inte ett avbrott.
• Håll koll på PSI och MemAvailable istället för att vänta på dmesg att få reda på vad som hänt i efterhand.
• Lämna 15 till 20 procent av RAM-minnet som reserv. Inställningar kan inte kompensera för en VPS som helt enkelt är för liten för arbetsbelastningen.

Om ditt minnestryck är strukturellt snarare än konfigurerbart behöver du mer RAM eller snabbare lagring med swap-stöd. FDC Servers VPS-paket körs på AMD EPYC med NVMe-lagring, vilket håller läsningar med swap-stöd tillräckligt snabba för att korta minnesöverbelastningar inte ska eskalera till avstängningar.