Când un server Linux intră în memory pressure, primul impuls este să te uiți la procese: cine consumă RAM, ce container a crescut, ce serviciu nu eliberează memoria. Uneori însă răspunsul nu este în lista de procese. O parte din memorie poate fi ținută de kernel: structuri slab, cache-uri interne, stive, tabele de pagini, memorie blocată sau alte alocări care nu se recuperează ușor când sistemul are nevoie de RAM.
Aici devine util page_owner, un mecanism din kernelul Linux documentat upstream, creat pentru a urmări cine a alocat fiecare pagină de memorie. Nu este o unealtă pentru „optimizări magice”, ci pentru diagnosticare serioasă: îți arată stack-ul de alocare, ordinul alocării și gruparea paginilor rămase alocate, astfel încât să poți lega consumul de o zonă reală din kernel.
De ce /proc/meminfo nu este suficient
/proc/meminfo este punctul de plecare. Câmpuri precum MemAvailable, Slab, SReclaimable, SUnreclaim, KReclaimable, Unevictable, KernelStack și PageTables spun în ce categorie stă memoria. Documentația kernel explică, de exemplu, că SUnreclaim este partea din Slab care nu poate fi recuperată sub presiune de memorie, iar KReclaimable include alocări kernel pe care sistemul va încerca să le recupereze.
Problema este că aceste câmpuri răspund la întrebarea „unde pare să fie memoria?”, nu la întrebarea „cine a alocat-o?”. Dacă SUnreclaim crește constant, poți bănui un cache slab sau o componentă kernel, dar nu ai încă dovada. Pentru dovadă ai nevoie de corelare: meminfo, slabinfo, shrinker debugfs și, când este disponibil, page_owner.
Ce face concret page_owner
page_owner înregistrează informații la momentul alocării paginilor: call stack-ul, ordinul alocării și metadate care permit agregarea ulterioară. Documentația Linux spune explicit că funcția este utilă pentru depanarea scurgerilor de memorie sau pentru identificarea unui „memory hogger”. În versiunile moderne, interfața page_owner_stacks poate arăta stack-uri și numărul de pagini de bază încă alocate, ceea ce oferă o vedere rapidă asupra zonelor în care se duce memoria.
Important: page_owner este dezactivat implicit. Kernelul trebuie să fie construit cu suportul necesar, iar la boot se adaugă parametrul page_owner=on. Dacă suportul există, dar opțiunea nu este activată la rulare, documentația notează că overhead-ul este marginal. Când este activat, trebuie totuși tratat ca instrument de diagnosticare, nu ca setare permanentă pe orice sistem de producție.
Flux sigur de investigație
Un flux defensiv începe cu simptomele. Verifici /proc/meminfo și urmărești dacă scade MemAvailable, dacă Slab sau SUnreclaim cresc, dacă apar valori mari la Unevictable sau KernelStack. Apoi te uiți la /proc/slabinfo sau la unelte precum slabtop, pentru a vedea care cache-uri slab au multe obiecte active. Dacă există shrinkere relevante, interfața debugfs pentru shrinker poate arăta ce componente au mecanisme de recuperare și cum raportează obiectele.
Pasul următor este page_owner. După activarea la boot și montarea debugfs, datele pot fi citite din /sys/kernel/debug/page_owner_stacks/. Interfața show_stacks grupează alocările după stack și afișează nr_base_pages. count_threshold permite filtrarea stack-urilor mici, ca să nu te pierzi în zgomot. Pentru analiză mai comodă, sursa kernel include unelte în tools/mm, precum page_owner_sort și page_owner_filter.
Cum identifici componenta kernel
Cheia este stack-ul de alocare. Dacă vezi funcții precum allocate_slab, ___slab_alloc sau kmem_cache_alloc, te uiți mai jos în stack pentru funcția care a cerut obiectele. Un exemplu din documentația page_owner arată alocări care trec prin sk_alloc și inet_create, indicând zona de networking, sau prin funcții XFS marcate cu [xfs], indicând filesystem-ul. Nu trebuie să sari direct la concluzia „bug”: poate fi o încărcare normală, un cache legitim, o configurație nepotrivită sau o interacțiune cu workload-ul.
Pentru rezultate credibile, compară probe în timp: înainte de workload, în timpul presiunii de memorie și după oprirea workload-ului. Dacă același stack crește și nu scade, iar meminfo arată creștere în zone nerecuperabile, ai un indiciu solid despre componenta de investigat. Dacă stack-ul aparține unui modul, verifici versiunea kernelului, distribuția, changelog-ul vendorului și eventualele rapoarte upstream înainte de a lua măsuri.
Limite și bune practici
page_owner nu explică singur cauza finală. El arată cine a alocat paginile, nu de ce politica de recuperare nu a funcționat sau dacă o creștere este anormală. Unele alocări timpurii pot avea informații mai puțin precise, iar accesul la debugfs trebuie protejat: expune detalii interne ale kernelului și nu ar trebui lăsat deschis utilizatorilor neautorizați.
Pentru administratori avansați, valoarea reală este reducerea presupunerilor. În loc să dai restart la servicii la întâmplare sau să ajustezi parametri VM fără diagnostic, page_owner îți oferă o hartă a alocărilor kernel. Folosit împreună cu meminfo, slabinfo și documentația oficială, te ajută să transformi „serverul pierde memorie” într-o întrebare mult mai precisă: ce componentă a kernelului ține paginile, cât de mult ține și în ce condiții se reproduce problema.
Surse
- Linux Kernel Documentation — page owner: Tracking about who allocated each page
- Linux Kernel Documentation — The /proc Filesystem
- Linux Kernel Documentation — Short users guide for the slab allocator
- Linux Kernel Documentation — Shrinker Debugfs Interface
- Linux Kernel Documentation — Documentation for /proc/sys/vm/
