Linuxi mäluhalduse selgitus: swap, OOM killer ja cgroups

Linux käsitleb mälu teistmoodi kui enamik operatsioonisüsteeme. Suur RAM-i kasutamine ei ole alati probleem – tuum kasutab vaba mälu aktiivselt vahemällu, et kiirendada kettalt lugemist. Kuid kui tekib tõeline mälukoormus, hakkavad tööle kolm mehhanismi: swap, OOM killer ja cgroups. Nende toimimise ja konfigureerimise mõistmine on see, mis eristab serverit, mis koormuse all sujuvalt aeglustub, serverist, mis kukub ilma hoiatuseta kokku.

Kuidas Linux haldab mälulehti

Iga protsess töötab oma virtuaalses aadressiruumis, mis 64-bitistes süsteemides ulatub kuni 128 TB-ni. Tuum kaardistab need virtuaalsed aadressid füüsilisse RAM-i leheküljetabelite kaudu, kusjuures Translation Lookaside Buffer (TLB) salvestab viimased otsingud vahemällu. TLB-tabamus võtab aega umbes 1 nanosekund; tabamuse puudumine maksab 20–100 nanosekundit, mis koguneb mäluintensiivsetes töökoormustes, nagu andmebaasid.

Füüsiline mälu on jagatud 4 KB lehekülgedeks ja tuum jagab need kahte kategooriasse:

• Failipõhised leheküljed — seotud kettal olevate failidega. Tuum võib tühjad leheküljed kõrvaldada või täidetud leheküljed tühjendada ilma vahetusmälu kasutamiseta.
• Anonüümsed leheküljed — heap- ja stack-mälu, millel puudub toetav fail. Need tuleb kirjutada vahemällu, enne kui tuum saab need vabastada.

Suure mälunõudlusega serverites tähendab anonüümsete lehtede suur osakaal, et vahemälu kaasatakse varakult. Jälgige si (swap in) ja so (vahetusmälust välja) veerge vmstat 1 — püsivad nullist erinevad väärtused on esimene hoiatus, et süsteem on koormuse all.

Jälgimiseks kasutage sobivat tööriista:

Üks levinud viga: vaadata free veergu free -h ja paanikasse sattumine. Oluline on available on see, mis loeb. See hõlmab mälu, mida tuum saab vajadusel vahemälust tagasi võtta. Server, mis näitab vaid 512 MB vaba, kuid 5 GB kättesaadavat mälu, ei ole hädas.

Kui mälu langeb alla künnise, hakkab tuuma kswapd daemon hakkab taustal lehti tagasi võtma. Kui sellest ei piisa, läheb tuum üle otsesele tagasivõtmisele, blokeerides protsesse, kuni lehed on vabastatud. Sellest tulenevadki latentsuse tõusud. Seadke hoiatus, kui MemAvailable langeb alla 10–15% kogu RAM-ist, et sul oleks aega reageerida.

Vahetusmälude konfigureerimine

Vahetusala on kettapiirkond – kas partitsioon või fail –, kuhu tuum viib mitteaktiivsed anonüümsed leheküljed, kui RAM-mälu täitub. Kiiruse vahe on märkimisväärne: DDR4 RAM-i latentsus on umbes 100 ns, samas kui NVMe SSD-del on see umbes 100 000 ns ja SATA SSD-del ligi 500 000 ns. Swap on turvapuhver, mitte lisamälu. Serveril, mis sõltub pidevalt swapist, on mäluprobleem, mida suurem swap ei lahenda.

Kasutage vahetusfaili, mitte partitsiooni. Selle suurust on lihtsam muuta ja see ei nõua partitsioonide ümberjaotamist.

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

Lisage fail /etc/fstab , et see säiliks ka pärast taaskäivitamist. chmod 600 samm on vajalik – kõiki RAM-ist välja lehekülgitud andmeid saab vahetusmälust lugeda, seega ei tohi fail olla kõigile loetav.

Pärast vahemälufaili loomist seadistage vm.swappiness. Vaikimisi väärtus 60 on agressiivne. Enamiku hosting-töökoormuste puhul soovitakse, et tuum eelistaks RAM-i ja kasutaks vahetusfaili ainult viimase abinõuna:

Vahetusala suuruse määramiseks: 1–2 GB on piisav 2 GB VPS-ile, mis peab toime tulema aeg-ajalt esinevate liikluspiikidega. Süsteemidel, millel on 8 GB või rohkem, on üldjuhul piisav fikseeritud 2–4 GB vahetusala. Eesmärk on anda tuumale survestusventiil külmade lehtede jaoks, mitte laiendada kogu adresseeritavat mälu.

RAM-i piiratud serveritel, millel on piisavalt CPU-võimsust, loob zram mällu kompresseeritud vahemäluala, vältides täielikult kettaseadme sisend-väljundoperatsioone. Seda tasub kaaluda mitme kasutajaga VPS-hostingutel, kus NVMe jagatakse kasutajate vahel. Jälgige sisend-väljundkonflikte, kui vahemälu asub samal seadmel kui andmebaasifailid – intensiivne vahetus ja suure läbilaskevõimega kettakirjutused ei sobi hästi kokku.

OOM-killer

Kui tuum on ammendanud RAM-i ja vahetusmälud ning ei suuda muude vahenditega piisavalt mälu vabastada, astub mängu OOM-killer. See hindab protsesse, kasutades oom_badness() funktsiooni:

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

Kõrgeima skooriga protsess lõpetatakse. Valem soosib suuri mälu tarbijaid ja tuum vältib mitme protsessi järjestikust lõpetamist, kontrollides, kas protsess on viimase 5 sekundi jooksul juba lõpetatud.

Logides ilmub kahte tüüpi OOM-sündmusi:

• Globaalne OOM — kogu süsteemil on RAM ja vahemälu otsas. Logidele lisatakse eesliide Out of memory:
• Cgroup OOM — konteiner või teenus on jõudnud oma memory.max piir. Logidele lisatakse eesliide Memory cgroup out of memory:

Varasemate OOM-sündmuste vaatamiseks:

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

Pöörake tähelepanu order väljale OOM-logides. Väärtus üle 0 viitab pigem mälu killustumisele kui täielikule ammendumisele — tuum ei suutnud leida piisavalt järjestikuseid lehekülgi isegi vaba mälu olemasolul.

Saate mõjutada, milliseid protsesse OOM-tapja sihib, reguleerides /proc/<pid>/oom_score_adj. Vahemik on -1000 (ei lõpeta kunagi) kuni +1000 (lõpetab esimesena). Systemd-haldatavate teenuste puhul seadistage see püsivalt üksuse failis:

[Service]
OOMScoreAdjust=-1000

Täiendavad sysctl-parameetrid OOM-käitumise häälestamiseks:

Proaktiivseks seireks vaadake /proc/pressure/memory (Pressure Stall Information, saadaval alates tuumast 4.20). Jälgige some avg10 väärtust: alla 5% on normaalne, püsiv üle 20% tähendab, et OOM-sündmus on tõenäoliselt tulemas. Tõusev allocstall loendur /proc/vmstat on veel üks varajane märk — see loendab otseseid vabastamisviivitusi, mis sageli eelnevad OOM-i lõpetamistele. Sellised tööriistad nagu systemd-oomd või earlyoom võivad reageerida PSI künnistele enne, kui tuuma OOM-tapja käivitub.

Cgroups ja mälupiirangud

Kontrollirühmad (cgroups) võimaldavad protsesse rühmadesse organiseerida ja kehtestada ranged ressursipiirangud. Need võeti kasutusele Linuxi versioonis 2.6.24 ja on aluseks konteinerite käitamiskeskkondadele, sealhulgas Docker, Podman, Kubernetes ja LXC. Tuum jälgib mälu kasutust iga cgrupi kohta, hõlmates anonüümset mälu, failipõhiseid lehti ja tuumaobjekte. Kui cgroup jõuab oma piirini, vabastab tuum selle grupi mälu või käivitab cgrupi ulatuses OOM-kill-i.

Cgroup v1 ja v2 erinevad peamiselt oma struktuuri poolest. V1 monteerib iga kontroller (mälu, CPU, I/O) eraldi kataloogi /sys/fs/cgroup/<controller>/, mis viib ebajärjekindla ressursside jälgimiseni. V2 kasutab ühtset hierarhiat /sys/fs/cgroup/. Kubernetes läks versioonis 1.25 vaikimisi üle v2-le ja lõpetas v1 toetamise versioonis 1.31.

Selleks, et kontrollida, millist versiooni teie süsteem kasutab:

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

cgroup2fs tähendab v2; tmpfs tähendab tavaliselt v1.

Peamised mälukontrollid cgroup v2-s:

Praktiline reegel: seadke memory.high umbes 10–20% alla memory.max , et anda tuumale ruumi taastamiseks enne kõva piiri saavutamist. Suuruse määramisel memory.max, lisage 20–30% rakenduse tippkasutuse peale, et arvestada lehekülje vahemäluga, mis arvestatakse cgroupi mälu kogumahust maha.

Haldage cgruppe pigem systemd kaudu kui kirjutades otse cgrupi failisüsteemi. Kasutage ühikufaili direktiive nagu MemoryMax=, MemoryHigh=ja MemoryMin= püsivate piirangute jaoks. Kiireteks testideks:

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

Veebiserveri töötajate rühmade puhul tagab memory.oom.group=1 tagab puhta lõpetamise, kui üks töötaja ületab oma piiri — maha ei jää ühtegi hüljatud protsessi. Andmebaasimootorite puhul memory.min kaitseb puhvripooli süsteemiülese koormuse all tagasivõtmise eest.

Mälukonfiguratsioon serveri rolli järgi

Õiged mälu seaded sõltuvad sellest, mida server teeb. Sama konfiguratsiooni rakendamine andmebaasile ja PHP veebiserverile kahjustab ühte neist.

MySQLi ja PostgreSQLi puhul eraldage 50–70% kättesaadavast RAM-ist innodb_buffer_pool_size, lülita välja Transparent Huge Pages, et vähendada latentsuse kõikumisi, ja kaitse protsessi OOMScoreAdjust=-900 süsteemi systemd-üksuse failis.

PHP-FPM puhul määra töötajate rühmade suurus vastavalt tegelikule mälukasutusele. Iga töötaja kasutab tavaliselt 30–100 MB. Jaga eraldatud RAM-mälu töötaja keskmise suurusega, et saada ohutu pm.max_children väärtus. Kasutage memory.max cgroups-is, et piirata töötajate rühma suurust.

Kirjutamisintensiivsete töökoormuste puhul seadke vm.dirty_ratio väärtuseks umbes 10% ja vm.dirty_background_ratio 3%ni. See tühjendab määrdunud lehekülgi sagedamini, vältides suuri sisend-väljund-seisakuid.

Tee tuuma häälestamine püsivaks, salvestades parameetrid faili /etc/sysctl.d/90-memory.conf. Käivitamisel rakendatud seaded kaovad taaskäivitamisel.

Soovitatavate väärtuste kokkuvõte rollide kaupa:

Kui teie töökoormus on väga tihe ja vajate serverit, millel on piisavalt võimsust nende poliitikate nõuetekohaseks rakendamiseks, tasub FDC pühendatud servereid kindlasti kaaluda.