Linux OOM killeri häälestamine VPS-ile

Linux OOM killer on tuuma viimane abinõu, kui mälu otsa saab: see valib protsessi ja lõpetab selle, et süsteem töötaks edasi. VPS-il, kus RAM-mälu on piiratud ja pole kuhugi tagasi pöörduda, on vaikimisi valik sageli vale. Teie andmebaas lõpetatakse, pikaajaliselt töötav tööprotsess jääb alles ja teie peate ise välja selgitama, miks. Käesolev juhend käsitleb seda, kuidas OOM-killer protsesse hindab, kuidas suunata seda hindamist teie kriitiliste teenuste poole ning kuidas kasutada c-gruppe, et üksik kontrolli alt väljunud protsess ei suudaks kaasa tõmmata kogu ülejäänud süsteemi.

Kuidas OOM-killer valib ohvri

Kui tuum ei suuda lehekülje vahemälust eemaldamise või vahetusmäluga piisavalt mälu vabastada, käivitab ta OOM-tapja. Igal protsessil on oom_score 0 ja 1000 vahel, mis tuleneb peamiselt selle Resident Set Size’ist (RSS) ja vahetusmälu kasutamisest. Kõrgeima skooriga protsess saab SIGKILL-i.

RSS domineerib arvutuses, mistõttu tapmine langeb peaaegu alati suurimale mälu tarbijale. See on sageli teie andmebaas, teie rakendusserver või mis tahes pikaajaline protsess, mis teeb kõige kasulikumat tööd. Protsess, mis tegelikult eraldamise käivitas, „kutsuja”, on harva see, mis lõpetatakse.

On kaks liiki OOM-sündmusi, mida tuleb eristada:

• Globaalne OOM: hostil (või teie VPS-il tervikuna) on RAM ja vahetusmälu otsas. Tuum skannib iga protsessi ja lõpetab kõrgeima skooriga protsessi.
• Cgroup OOM: konkreetne cgroup on jõudnud oma mälupiirini. Tuum lõpetab protsessid ainult selles cgroupis, isegi kui ülejäänud süsteemis on vaba mälu.

Kui olete konfigureerinud systemd-üksuse piirangud või kasutate konteinerid, on enamik teie OOM-sündmustest cgroup OOM-id. See on hea: mõju ulatus on piiratud.

Mälukoormuse tuvastamine enne süsteemi kokkujooksmist

OOM-sündmused ei ole peaaegu kunagi ootamatud. Tavaliselt on esmalt periood, mil koormus kasvab, ja seire eesmärk on see selle perioodi jooksul märgata.

free -h annab teile süsteemi ülevaate. Oluline veerg on available, mitte free: see kajastab taastatavat lehekülje vahemälud ja näitab, mida sa tegelikult saad eraldada ilma vahetamiseta. Hoia MemAvailable umbes 10–15 protsendi piires MemTotal tippkoormuse ajal.

Protsessipõhise jaotuse jaoks sorteerige RSS järgi:

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

Või kasutage htop ja sorteerige RES. Siin kuvatavad väärtused sisestatakse otse tuuma hindamissüsteemi, seega on esimesed kanded kõige tõenäolisemad OOM-sihtmärgid.

Tuumades 4.20 ja uuemates on Pressure Stall Information varajane hoiatussüsteem, mida tasub seirega ühendada:

cat /proc/pressure/memory

Arv some avg10 joonis näitab protsenti ajast, mil viimase kümne sekundi jooksul on vähemalt üks ülesanne mälu ootamisel seisma jäänud. Alla 5 protsendi on normaalne. Püsivad väärtused üle 10 protsendi tähendavad, et süsteem kulutab reaalajas aega mälu vabastamisele ja OOM-i põhjustatud protsessi lõpetamine on tõenäoline.

Swap thrashing kuvatakse vmstat 1 nullist erineva si ja so veergudes, mis püsivad aja jooksul. Väike kogus resident-swap'i on ohutu. Pidev swap-in ja swap-out ei ole.

Kriitiliste protsesside kaitsmine oom_score_adj abil

Kerneli arvutatud skoor võib olla protsessipõhiselt kallutatud oom_score_adjskaalal -1000 (immuunne) kuni +1000 (tapa mind esimesena). Korrigeerimine lisatakse otse lõppskoorile.

Ühekordseks muudatuseks töötava protsessi suhtes:

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

Kõik, mida soovid säilitada taaskäivituste järel, seadista süsteemiüksuses. See on õige koht sshd-le, andmebaasile ja kõigele muule, mida sa kaotada ei saa:

[Service]
OOMScoreAdjust=-900

Mõistlikud algseaded, millest alustada:

• sshd: -1000. Kui kaotate mälukriisi ajal kaugjuurdepääsu, muutub taastamine palju raskemaks.
• MySQL, PostgreSQL, Redis: -800 kuni -900. Tugev kaitse, ilma et need muutuksid tõeliselt katastroofilises olukorras täiesti puutumatuteks.
• Rakenduste töötajad, partiitööd, croni ülesanded: +100 kuni +500. Need on protsessid, mille lõpetamist eelistate oma andmebaasi kaotamisele.

Ärge seadke kõike väärtusele -1000. Kui midagi ei saa lõpetada, satub tuum lõpuks paanikasse või külmub kinni, mis on veelgi hullem.

Mälu piiramine cgroupide ja systemd abil

Skooride kohandamine mõjutab seda, kes tapetakse. C-grupid mõjutavad seda, kas globaalne tapmine üldse toimub. Andes igale teenusele kindla ülempiiri, suunate mäluvead ühte c-gruppi, selle asemel et lasta ühel protsessil kogu VPS-i tühjendada.

Systemd-üksuse failis:

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

MemoryHigh on pehme piirang: tuum võtab selle piiri ületamisel cgroupist agressiivselt lehekülgi tagasi, kuid ei lõpeta midagi. MemoryMax on range ülempiir. Kui cgroup püüab seda ületada, lõpetab tuum protsessi cgroupi sees. Kui Restart=on-failure teenus taastub kohe.

Cgroup v2-s (Ubuntu 22.04 ja uuemad versioonid, viimased Debianid, RHEL 9) memory.oom.group lõpetatakse kõik cgroupi protsessid korraga, selle asemel et jätta maha orvud. Kasulik mitme protsessiga teenuste puhul, nagu PHP-FPM-i poolid, kus poolikult lõpetatud grupp hakkab ebaõigesti toimima.

Mõned rakendusespetsiifilised märkused, mida tasub rakendada:

• PHP-FPM: seadistage pm = ondemand väikestele VPS-instantsidele ja suurus pm.max_children vastavalt töötaja keskmisele RSS-ile, mitte vaikimisi väärtusele. 2 GB VPS-il 4 GB varuga mõõdetud pool tekitab OOM-i esimesel täitumisel.
• Node.js: piirata V8-heapi suurusega --max-old-space-size=512 (MB-des). Ilma selle piiranguta kasvab Node rõõmsalt, kuni kernel sekkub.
• MySQL ja PostgreSQL: innodb_buffer_pool_size ja shared_buffers peaksid jätma piisavalt vaba ruumi operatsioonisüsteemi lehekülje vahemälule, ühendusmälule ja muudele masinas asuvatele kasutajatele. Vaikimisi eeldatakse pühendatud serverit.

Logide lugemine pärast OOM-sündmust

Kui OOM-killer käivitub, salvestab tuum ringpuhvrisse üksikasjaliku aruande. Saate selle kätte järgmise käskuga:

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

Hoolikalt lugemiseks mõeldud plokk algab käivitajaga ja lõpeb ohvriga. Tuum trükib välja täieliku ülesannete loendi koos iga protsessi RSS-i, vahetusmälu kasutuse ja lõpliku oom_score_adj. Kolm asja on kontrollimist väärt:

• Piirang. CONSTRAINT_NONE tähendab globaalset OOM-i, CONSTRAINT_MEMCG tähendab, et cgroup jõudis oma piirini. Lahendus on igal juhul erinev.
• Free swap. Kui see on 0kB, on nii RAM kui ka vahetusruum ammendunud. Lisage vahetusruumi, suurendage MemoryMax süüdlase prioriteeti või vähendage samaaegsust.
• Ohvri skoor võrreldes kõigi teistega. Kui ohvri skoor ei ole palju kõrgem kui järgnevatel protsessidel, ei tee teie oom_score_adj väärtused ei tee piisavalt tööd. Suurendage vahet.

Spetsiaalselt cgroupi OOM-ide puhul asub kill-loendur memory.events cgrupi sees:

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

Tõusev oom_kill arv tähendab, et teenus jõuab korduvalt oma piirini. See on märk, et tuleb suurendada MemoryMax, töökoormust analüüsida või teenust suuremale plaanile üle viia, mitte seda lõputult uuesti käivitada.

Kokkuvõte

OOM-killer'i häälestamine ei tähenda selle kaotamist. See tähendab kontrolli selle üle, milline protsess kannatab, kui mälu otsa saab, ja mõju ulatuse vähendamist, kui see juhtub. Tootmises kehtiv reegel:

• Kaitse teenuseid, mida sa ei saa endale kaotada, eriti sshd ja andmebaase.
• Piirake kõike muud MemoryMax süsteemi systemd-üksusesse, nii et üksikud tõrked põhjustavad vaid taaskäivituse, mitte katkestuse.
• Jälgige PSI-d ja MemAvailable selle asemel, et oodata dmesg , et see teile hiljem olukorda kirjeldaks.
• Jätke 15–20 protsenti RAM-ist varuks. Häälestamine ei suuda kompenseerida VPS-i, mis on töökoormuse jaoks lihtsalt liiga väike.

Kui teie mälukoormus on pigem struktuuriline kui konfigureeritav, vajate rohkem RAM-i või kiiremat vahetusmäluga salvestusruumi. FDC Serversi VPS-paketid töötavad AMD EPYC-protsessoritel koos NVMe-salvestusruumiga, mis hoiab vahetusmäluga lugemise piisavalt kiire, et lühiajalised mälukoormuse tõusud ei eskaleeruks süsteemi sulgemiseks.