Linux OOM-killer afstemmen voor VPS

De Linux OOM-killer is het laatste redmiddel van de kernel wanneer het geheugen opraakt: hij kiest een proces en beëindigt dit om het systeem in leven te houden. Op een VPS, waar het RAM-geheugen beperkt is en er geen uitwijkmogelijkheid is, is de standaardkeuze vaak de verkeerde. Uw database wordt beëindigd, een langlopende worker blijft bestaan en u moet zelf uitzoeken waarom. Deze gids behandelt hoe de OOM-killer processen beoordeelt, hoe u die beoordeling kunt beïnvloeden ten gunste van uw kritieke diensten en hoe u cgroups kunt gebruiken zodat één enkel op hol geslagen proces niet de rest van het systeem mee ten val kan brengen.

Hoe de OOM-killer een slachtoffer kiest

Wanneer de kernel niet genoeg geheugen kan vrijmaken via het verwijderen van paginacache of swap, roept deze de OOM-killer aan. Elk proces heeft een oom_score score tussen 0 en 1000, die grotendeels wordt afgeleid van de Resident Set Size (RSS) en het swapgebruik. Het proces met de hoogste score krijgt een SIGKILL.

RSS domineert de berekening, en daarom treft de kill bijna altijd de grootste geheugenverbruiker. Dat is vaak uw database, uw applicatieserver of welk langlopend proces dan ook dat het nuttigste werk verricht. Het proces dat de toewijzing daadwerkelijk heeft geactiveerd, de "invoker", is zelden het proces dat wordt beëindigd.

Er zijn twee soorten OOM-gebeurtenissen die u uit elkaar moet houden:

• Global OOM: de host (of uw VPS als geheel) heeft geen RAM en swap meer. De kernel scant elk proces en beëindigt het proces met de hoogste score.
• Cgroup OOM: een specifieke cgroup heeft zijn geheugenlimiet bereikt. De kernel beëindigt alleen processen binnen die cgroup, zelfs als de rest van het systeem nog geheugen over heeft.

Als u systemd-unitlimieten hebt geconfigureerd of containers draait, zullen de meeste van uw OOM-gebeurtenissen cgroup OOM's zijn. Dat is een goede zaak: de impact blijft beperkt.

Geheugendruk opsporen vóór de crash

OOM-gebeurtenissen komen bijna nooit plotseling voor. Meestal is er eerst een periode waarin de druk toeneemt, en het doel van monitoring is om dit binnen die periode op te merken.

free -h geeft u het systeemoverzicht. De kolom die van belang is, is available, niet free: deze kolom geeft de terugwinbare paginacache weer en laat zien wat u daadwerkelijk kunt toewijzen zonder te swappen. Houd MemAvailable boven ongeveer 10 tot 15 procent van MemTotal bij piekbelasting.

Voor toewijzing per proces sorteert u op RSS:

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

Of gebruik htop en sorteer op RES. De waarden die u hier ziet, worden direct meegenomen in de score van de kernel, dus de bovenste vermeldingen zijn de meest waarschijnlijke OOM-doelen.

Op kernels 4.20 en nieuwer is Pressure Stall Information het vroegtijdige waarschuwingssysteem dat de moeite waard is om in de monitoring op te nemen:

cat /proc/pressure/memory

Het some avg10 cijfer is het percentage van de tijd dat ten minste één taak de afgelopen tien seconden is vastgelopen in afwachting van geheugen. Minder dan 5 procent is prima. Aanhoudende waarden boven de 10 procent betekenen dat het systeem reële tijd besteedt aan het vrijmaken van geheugen, en een OOM-kill is aannemelijk.

Swap-thrashing wordt weergegeven in vmstat 1 als niet-nul si en so kolommen die in de loop van de tijd aanhouden. Een kleine hoeveelheid resident swap is onschadelijk. Constant in- en uitwisselen is dat niet.

Kritieke processen beschermen met oom_score_adj

De score die de kernel berekent, kan per proces worden aangepast via oom_score_adj, op een schaal van -1000 (immuun) tot +1000 (dood mij als eerste). De aanpassing wordt direct aan de eindscore toegevoegd.

Voor een eenmalige wijziging tegen een actief proces:

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

Voor alles wat je na herstarts wilt behouden, stel je het in de systemd-unit in. Dat is de juiste plek voor sshd, je database en al het andere dat je niet kunt missen:

[Service]
OOMScoreAdjust=-900

Verstandige standaardinstellingen om mee te beginnen:

• sshd: -1000. Als je de externe toegang verliest tijdens een geheugencrisis, wordt herstel een stuk moeilijker.
• MySQL, PostgreSQL, Redis: -800 tot -900. Sterke bescherming zonder ze volledig onaantastbaar te maken in een echt rampzalige situatie.
• Applicatiewerkers, batchtaken, cron-taken: +100 tot +500. Dit zijn de processen die je liever ziet stoppen dan je database.

Stel niet alles in op -1000. Als niets kan worden beëindigd, zal de kernel uiteindelijk in paniek raken of vastlopen, wat nog erger is.

Geheugen beperken met cgroups en systemd

Het aanpassen van scores beïnvloedt wie er wordt beëindigd. Cgroups beïnvloeden of de globale beëindiging ooit plaatsvindt. Door elke service een harde bovengrens te geven, duw je geheugenstoringen in één enkele cgroup in plaats van één proces de hele VPS te laten leegtrekken.

In een systemd-unitbestand:

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

MemoryHigh is een zachte begrenzing: de kernel vordert agressief pagina's terug van de cgroup boven dit punt, maar beëindigt niets. MemoryMax is de harde limiet. Als de cgroup probeert om daarboven te toewijzen, beëindigt de kernel een proces binnen de cgroup. Met Restart=on-failure komt de service direct weer op.

Op cgroup v2 (Ubuntu 22.04 en later, recente Debian, RHEL 9), memory.oom.group worden alle processen in de cgroup tegelijk beëindigd in plaats van dat er 'wezen' achterblijven. Handig voor diensten met meerdere processen zoals PHP-FPM-pools, waar een half beëindigde groep zich vreemd gaat gedragen.

Een paar toepassingsspecifieke opmerkingen die de moeite waard zijn om toe te passen:

• PHP-FPM: stel pm = ondemand op kleine VPS-instances en stel de grootte pm.max_children op de gemiddelde RSS per worker, niet op de standaardwaarde. Een pool met 4 GB ruimte op een 2 GB VPS zal de eerste keer dat deze vol raakt een OOM-fout geven.
• Node.js: beperk de V8-heap met --max-old-space-size=512 (in MB). Zonder deze instelling zal Node vrolijk blijven groeien totdat de kernel ingrijpt.
• MySQL en PostgreSQL: innodb_buffer_pool_size en shared_buffers moet voldoende ruimte overhouden voor de paginacache van het besturingssysteem, het verbindingsgeheugen en eventuele andere tenants op de server. De standaardinstellingen gaan uit van een dedicated server.

De logbestanden lezen na een OOM-gebeurtenis

Wanneer de OOM-killer wordt geactiveerd, dumpt de kernel een gedetailleerd rapport in de ringbuffer. Haal dit op met:

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

Het blok dat je zorgvuldig moet lezen, begint met de aanroeper en eindigt met het slachtoffer. De kernel drukt een volledige takenlijst af met de RSS, het swapgebruik en de uiteindelijke oom_score_adj. Drie zaken zijn het controleren waard:

• De beperking. CONSTRAINT_NONE betekent een globale OOM, CONSTRAINT_MEMCG betekent dat een cgroup zijn limiet heeft bereikt. De oplossing is in elk geval anders.
• Free swap. Als dit 0kB, waren zowel het RAM-geheugen als de swap uitgeput. Voeg swap toe, verhoog MemoryMax op de boosdoener, of verminder de gelijktijdigheid.
• De score van het slachtoffer ten opzichte van al het andere. Als de score van het slachtoffer niet veel hoger is dan die van de volgende paar processen, oom_score_adj waarden doen niet genoeg werk. Vergroot de kloof.

Specifiek voor cgroup OOM's bevindt de kill-teller zich memory.events binnen de cgroup:

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

Een stijgend oom_kill teller betekent dat de service herhaaldelijk zijn limiet bereikt. Dat is een signaal om MemoryMax, de werklast te profileren of de service naar een groter abonnement te verplaatsen, in plaats van deze steeds opnieuw te starten.

Tot slot

Het afstemmen van de OOM-killer gaat niet over het wegwerken ervan. Het gaat erom te bepalen welk proces de prijs betaalt wanneer het geheugen opraakt, en de impact te beperken wanneer dit gebeurt. Het patroon dat in de productie standhoudt:

• Bescherm de services die u niet kunt missen, met name sshd en uw databases.
• Beperk al het andere met MemoryMax in een systemd-unit, zodat één enkele runaway een enkele herstart betekent, en geen uitval.
• Houd PSI in de gaten en MemAvailable in plaats van te wachten tot dmesg dat je achteraf pas te horen krijgt wat er is gebeurd.
• Laat 15 tot 20 procent van het RAM-geheugen vrij als reserve. Afstemming kan niet compenseren voor een VPS die simpelweg te klein is voor de werklast.

Als uw geheugendruk structureel is in plaats van configureerbaar, heeft u meer RAM of snellere opslag met swap-back-up nodig. De VPS-pakketten van FDC Servers draaien op AMD EPYC met NVMe-opslag, waardoor leesbewerkingen met swap-back-up snel genoeg blijven zodat korte geheugenpieken niet escaleren tot afsluitingen.