Când un sistem Linux intră sub presiune de memorie, problema nu este doar „cât RAM mai există”. Contează ce pagini sunt active, ce pagini pot fi eliberate fără impact major și cât de des ajunge kernelul să evacueze exact memoria de care aplicațiile au nevoie imediat după aceea. Aici apare Multi-Gen LRU, sau MGLRU, o implementare alternativă de page reclaim documentată în kernelul Linux.
Pe scurt, MGLRU împarte paginile în generații, în loc să trateze vechimea lor doar prin mecanismele LRU clasice. Ideea este să ofere kernelului o imagine mai bună asupra „vârstei” și folosirii reale a paginilor, astfel încât reclaim-ul să fie mai eficient când memoria devine insuficientă.
Cum gândește MGLRU memoria
Documentația kernelului descrie Multi-Gen LRU ca o implementare alternativă LRU care optimizează page reclaim și poate îmbunătăți performanța sub presiune de memorie. Page reclaim este mecanismul prin care kernelul decide ce pagini pot fi păstrate în RAM și ce pagini pot fi evacuate. Decizia influențează direct eficiența memoriei, utilizarea CPU de către kswapd și comportamentul sistemului când aplicațiile cer mai multă memorie decât este confortabil disponibilă.
Într-un sistem clasic, simptomele de thrashing se văd repede: aplicațiile răspund greu, interfața are întârzieri, discul sau swap-ul sunt solicitate agresiv, iar CPU-ul poate fi consumat de munca de recuperare a memoriei în loc de aplicațiile utile. MGLRU nu face magie și nu înlocuiește RAM-ul lipsă, dar poate ajuta kernelul să ia decizii mai bune despre ce merită păstrat.
Ce sunt generațiile de pagini
O generație poate fi înțeleasă ca un grup de pagini apropiate ca „prospețime” a accesului. Paginile folosite recent tind să rămână în generații mai tinere, iar paginile care nu mai sunt accesate ajung candidate mai bune pentru evacuare. Pentru administrator, ideea practică este simplă: nu urmărești doar memoria liberă, ci și dacă sistemul aruncă prea repede pagini care fac parte din working set-ul real al aplicațiilor.
Working set-ul înseamnă memoria de care o aplicație are nevoie într-un interval relevant de timp ca să funcționeze fluent. Dacă acest set este evacuat și apoi încărcat din nou repetat, apare thrashing-ul. În loc ca sistemul să muncească pentru utilizator, muncește să mute pagini înainte și înapoi.
Ce verifici înainte de tuning
Primul pas este să confirmi că sistemul folosește un kernel construit cu suport pentru MGLRU. Documentația indică opțiunile CONFIG_LRU_GEN=y și, pentru activare implicită, CONFIG_LRU_GEN_ENABLED=y. La rulare, ABI-ul stabil este în /sys/kernel/mm/lru_gen/.
Fișierul enabled controlează componentele principale. Valoarea 0x0001 reprezintă switch-ul principal pentru Multi-Gen LRU. Valoarea 0x0002 se referă la curățarea bitului accessed în intrările leaf ale tabelelor de pagini în batch-uri mari, acolo unde hardware-ul permite. Valoarea 0x0004 extinde comportamentul și la intrări non-leaf, tot unde este suportat. Documentația mai arată că y și n pot aplica setarea pentru componentele disponibile.
Aceste detalii contează pentru că un sistem poate avea MGLRU disponibil, dar nu complet activ în forma pe care o presupui. Înainte de concluzii, trebuie verificată starea reală a kernelului și a sysfs-ului, nu doar versiunea distribuției.
Reducerea thrashing-ului cu min_ttl_ms
Pentru desktopuri și laptopuri, documentația kernelului menționează explicit prevenirea thrashing-ului prin /sys/kernel/mm/lru_gen/min_ttl_ms. Utilizatorul poate seta o valoare N pentru a împiedica evacuarea working set-ului din ultimele N milisecunde. Valoarea implicită 0 înseamnă că opțiunea este dezactivată.
Atenția importantă este că această setare nu creează memorie suplimentară. Dacă working set-ul protejat nu poate fi păstrat în RAM, se poate ajunge la OOM killer. Documentația dă ca reper N=1000 pentru reducerea întârzierilor perceptibile severe și menționează valori mai mari, precum 3000, cu riscul unor omorâri premature de procese. Cu alte cuvinte, min_ttl_ms este o supapă de presiune, nu o soluție universală.
În practică, abordarea sănătoasă este testarea graduală într-un mediu controlat. Se urmăresc latențele, swap-ul, activitatea kswapd, evenimentele OOM și comportamentul aplicațiilor reale. Dacă o valoare reduce blocajele vizibile, dar crește riscul de terminare a proceselor, tuning-ul nu este câștigat, ci doar a mutat problema.
Debug fără concluzii grăbite
Kernelul oferă și /sys/kernel/debug/lru_gen și /sys/kernel/debug/lru_gen_full pentru funcții experimentale, comenzi și statistici suplimentare. Acestea sunt utile pentru analiză avansată, dar nu ar trebui transformate în rețete copiate direct pe servere de producție. Pe sisteme critice, orice modificare legată de memorie trebuie testată întâi pe staging sau pe un nod comparabil, cu posibilitate clară de revenire.
Multi-Gen LRU este valoros mai ales pentru că schimbă conversația: de la „mai eliberăm niște RAM” la „ce pagini merită păstrate pentru ca sistemul să rămână fluid”. Pentru administratorii Linux avansați, generațiile de pagini oferă un mod mai nuanțat de a citi presiunea de memorie. Dar regula rămâne aceeași: măsori, schimbi puțin, observi și revii dacă efectul real nu confirmă ipoteza.
