Explicația gestionării memoriei Linux: swap, OOM killer și cgroups

Linux gestionează memoria diferit față de majoritatea sistemelor de operare. Utilizarea ridicată a memoriei RAM nu este întotdeauna o problemă — kernelul folosește în mod activ memoria liberă pentru cache, pentru a accelera citirea de pe disc. Dar când presiunea asupra memoriei reale crește, trei mecanisme preiau controlul: swap, OOM killer și cgroups. Înțelegerea modului în care se comportă fiecare dintre ele și a modului în care se configurează reprezintă diferența dintre un server care se degradează treptat sub sarcină și unul care se blochează fără avertisment.

Cum gestionează Linux paginile de memorie

Fiecare proces rulează în propriul spațiu de adrese virtuale, de până la 128 TB pe sistemele pe 64 de biți. Kernelul mapează aceste adrese virtuale în memoria RAM fizică prin tabele de pagini, cu Translation Lookaside Buffer (TLB) care memorează în cache căutările recente. O accesare TLB durează aproximativ 1 nanosecundă; o ratare costă 20–100 nanosecunde, ceea ce se acumulează în sarcini de lucru care solicită intens memoria, cum ar fi bazele de date.

Memoria fizică este împărțită în pagini de 4 KB, iar kernelul le împarte în două categorii:

• Pagini susținute de fișiere — legate de fișierele de pe disc. Kernelul poate renunța la cele curate sau le poate goli pe cele murdare fără a avea nevoie de swap.
• Pagini anonime — memorie heap și stack fără fișier de rezervă. Acestea trebuie scrise în swap înainte ca kernelul să le poată elibera.

Pe serverele cu cerințe mari de memorie, o proporție mare de pagini anonime înseamnă că swap-ul este implicat devreme. Urmăriți si (swap in) și so (swap out) din vmstat 1 — valorile persistente diferite de zero sunt primul semnal de avertizare că sistemul este sub presiune.

Pentru monitorizare, folosiți instrumentul potrivit pentru această sarcină:

O greșeală frecventă: urmărirea free coloana free -h și a intra în panică. Ceea ce contează este coloana available este cea care contează. Aceasta include memoria pe care kernelul o poate recupera din cache la cerere. Un server care afișează doar 512 MB liberi, dar 5 GB disponibili, nu are probleme.

Când memoria scade sub un prag, kswapd demonul începe să recupereze pagini în fundal. Dacă asta nu este suficient, kernelul trece la recuperare directă, blocând procesele până când paginile sunt eliberate. De aici provin vârfurile de latență. Setați o alertă când MemAvailable scade sub 10–15% din RAM-ul total, astfel încât să aveți timp să reacționați.

Configurarea swap

Swap-ul este o zonă de pe disc — fie o partiție, fie un fișier — în care kernel-ul mută paginile anonime inactive atunci când memoria RAM se umple. Diferența de viteză este semnificativă: memoria RAM DDR4 are o latență de aproximativ 100 ns, în timp ce SSD-urile NVMe au o latență de aproximativ 100.000 ns, iar SSD-urile SATA se apropie de 500.000 ns. Swap-ul este un tampon de siguranță, nu memorie RAM suplimentară. Un server care se bazează constant pe swap are o problemă de memorie pe care un swap mai mare nu o va rezolva.

Utilizați un fișier swap în locul unei partiții. Este mai ușor de redimensionat și nu necesită repartiționare.

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

Adăugați fișierul /etc/fstab pentru a persista la reporniri. chmod 600 pas este necesar — orice date paginate din RAM sunt citibile din swap, deci fișierul nu trebuie să fie citibil de către toți utilizatorii.

După crearea swap-ului, reglați vm.swappiness. Valoarea implicită de 60 este agresivă. Pentru majoritatea sarcinilor de găzduire, doriți ca kernelul să prefere memoria RAM și să utilizeze swap-ul doar ca ultimă soluție:

Pentru dimensiunea swap: 1–2 GB este suficient pentru un VPS de 2 GB care gestionează vârfuri ocazionale de trafic. Pe sistemele cu 8 GB sau mai mult, un swap fix de 2–4 GB este, în general, suficient. Scopul este de a oferi kernel-ului o supapă de presiune pentru paginile reci, nu de a extinde memoria totală adresabilă.

Pe serverele cu memorie RAM limitată, dar cu CPU suficient de puternic, zram creează o zonă de swap comprimată în memorie, evitând complet operațiunile de I/O pe disc. Merită luat în considerare pe gazdele VPS multi-tenant unde NVMe este partajat între chiriași. Fii atent la conflictele de I/O dacă swap-ul se află pe același dispozitiv cu fișierele bazei de date — swap-ul intens și scrierile pe disc cu debit mare nu coexistă bine.

OOM killer

Când kernelul epuizează memoria RAM și swap și nu poate recupera suficientă memorie prin alte mijloace, intervine OOM killer. Acesta evaluează procesele folosind funcția oom_badness() funcția:

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

Procesul cu cel mai mare scor este oprit. Formula favorizează consumatorii mari de memorie, iar kernelul evită oprirea mai multor procese în succesiune rapidă, verificând dacă un proces a fost deja oprit în ultimele 5 secunde.

În jurnale apar două tipuri de evenimente OOM:

• OOM global — întregul sistem a epuizat memoria RAM și spațiul de swap. Jurnalele au prefixul Out of memory:
• Cgroup OOM — un container sau un serviciu a atins memory.max . Jurnalele au prefixul Memory cgroup out of memory:

Pentru a revizui evenimentele OOM anterioare:

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

Acordați atenție câmpului order din jurnalele OOM. O valoare mai mare de 0 sugerează fragmentarea memoriei mai degrabă decât epuizarea totală — kernelul nu a putut găsi suficiente pagini contiguă chiar și cu memorie liberă disponibilă.

Puteți influența procesele vizate de OOM killer ajustând /proc/<pid>/oom_score_adj. Intervalul este de la -1000 (nu ucide niciodată) la +1000 (ucide primul). Pentru serviciile gestionate de systemd, setați acest lucru permanent în fișierul unit:

[Service]
OOMScoreAdjust=-1000

Parametri sysctl suplimentari pentru reglarea comportamentului OOM:

Pentru monitorizare proactivă, verificați /proc/pressure/memory (Informații despre blocarea din cauza presiunii, disponibile începând cu kernelul 4.20). Urmăriți some avg10 : sub 5% este o valoare sănătoasă, menținerea peste 20% înseamnă că este probabil să apară un eveniment OOM. Un contor în creștere allocstall contorului /proc/vmstat este un alt semnal timpuriu — acesta numără blocările de recuperare directă, care adesea preced terminările OOM. Instrumente precum systemd-oomd sau earlyoom pot acționa la pragurile PSI înainte ca OOM killer-ul kernel-ului să se declanșeze.

Cgroups și limitele de memorie

Grupurile de control (cgroups) vă permit să organizați procesele în grupuri și să impuneți limite stricte de resurse. Introduse în Linux 2.6.24, acestea stau la baza mediilor de execuție a containerelor, inclusiv Docker, Podman, Kubernetes și LXC. Kernelul urmărește utilizarea memoriei pe cgroup, acoperind memoria anonimă, paginile susținute de fișiere și obiectele kernelului. Dacă un cgroup atinge limita, kernelul recuperează memoria din cadrul acelui grup sau declanșează o oprire OOM la nivel de cgroup.

Cgroup v1 și v2 diferă în principal prin modul în care sunt structurate. V1 montează fiecare controler (memorie, CPU, I/O) separat sub /sys/fs/cgroup/<controller>/, ceea ce duce la o urmărire inconsistentă a resurselor. V2 utilizează o ierarhie unificată la /sys/fs/cgroup/. Kubernetes a trecut la v2 ca versiune implicită în versiunea 1.25 și a renunțat la suportul pentru v1 în 1.31.

Pentru a verifica ce versiune utilizează sistemul dvs.:

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

cgroup2fs înseamnă v2; tmpfs înseamnă de obicei v1.

Comenzile cheie de memorie în cgroup v2:

O regulă practică: setați memory.high cu aproximativ 10–20% mai puțin memory.max pentru a oferi kernel-ului spațiu de recuperare înainte de a atinge limita strictă. Când dimensionați memory.max, adăugați 20–30% peste utilizarea maximă a aplicației pentru a ține cont de cache-ul de pagini, care se scade din totalul memoriei cgroup.

Gestionați grupurile c prin systemd, mai degrabă decât să scrieți direct în sistemul de fișiere al grupului c. Folosiți directive din fișierul unit, cum ar fi MemoryMax=, MemoryHigh=, și MemoryMin= pentru limite persistente. Pentru teste rapide:

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

Pentru grupurile de lucrători ale serverului web, setarea memory.oom.group=1 asigură o oprire curată dacă un worker depășește limita — fără procese orfane rămase în urmă. Pentru motoarele de baze de date, memory.min protejează buffer pool-ul împotriva recuperării sub presiunea la nivel de sistem.

Configurarea memoriei în funcție de rolul serverului

Setările corecte de memorie depind de ceea ce face serverul. Aplicarea aceleiași configurații la o bază de date și la un server web PHP va afecta unul dintre ele.

Pentru MySQL și PostgreSQL, alocați 50–70% din memoria RAM disponibilă pentru innodb_buffer_pool_size, dezactivați Transparent Huge Pages pentru a reduce vârfurile de latență și protejați procesul cu OOMScoreAdjust=-900 în fișierul unit systemd.

Pentru PHP-FPM, dimensionați grupurile de lucrători în funcție de utilizarea reală a memoriei. Fiecare lucrător utilizează de obicei 30–100 MB. Împărțiți memoria RAM alocată la dimensiunea medie a unui lucrător pentru a obține o pm.max_children . Utilizați memory.max în cgroups pentru a limita grupul.

Pentru sarcini de lucru cu scriere intensă, setați vm.dirty_ratio la aproximativ 10% și vm.dirty_background_ratio la 3%. Aceasta golește paginile modificate mai frecvent, evitând blocajele mari de I/O.

Asigurați-vă că optimizarea kernelului este persistentă salvând parametrii în /etc/sysctl.d/90-memory.conf. Setările aplicate în timpul rulării se pierd la repornire.

Pentru un rezumat al valorilor recomandate în funcție de rol:

Dacă rulați sarcini de lucru cu densitate ridicată și aveți nevoie de un server cu capacitate suficientă pentru a aplica aceste politici în mod corespunzător, merită să aruncați o privire la serverele dedicate ale FDC.