Când o aplicație pare „înghețată” pentru câteva secunde sau un server Linux răspunde greu doar în anumite momente, cauza nu este mereu vizibilă în logurile obișnuite. Uneori întârzierea apare într-un lanț scurt de funcții din kernel: o operațiune de I/O, o blocare, o cale de rețea sau o zonă de sincronizare care ține prea mult. Pentru astfel de investigații, ftrace rămâne una dintre cele mai utile unelte incluse în kernelul Linux.
Partea interesantă pentru administratorii avansați este că function_graph tracer poate arăta nu doar ce funcții sunt apelate, ci și cât timp petrece kernelul în ele. Nu ai nevoie să reconstruiești kernelul, dacă distribuția ta are ftrace și tracerul function_graph deja compilate. Verificarea se face direct în tracefs, de obicei în /sys/kernel/tracing.
Ce este function_graph tracer
Spre deosebire de tracerul simplu de funcții, function_graph urmărește intrarea și ieșirea din funcții și afișează apelurile sub formă de arbore. Rezultatul seamănă cu o hartă a drumului parcurs prin kernel: vezi funcția de pornire, funcțiile chemate de ea și durata raportată la revenire.
Documentația kernelului precizează că valorile de timp din ftrace sunt exprimate în microsecunde. Opțiunea funcgraph-duration afișează durata la finalul fiecărei funcții, iar funcgraph-overhead poate marca vizual apelurile care depășesc anumite praguri interne de întârziere. Pentru investigații reale, aceste două opțiuni sunt mai utile decât un flux brut de nume de funcții.
De ce nu trebuie recompilat kernelul
ftrace funcționează prin infrastructura de tracing deja prezentă în kernel. Dacă available_tracers conține function_graph, tracerul poate fi activat prin current_tracer. În distribuțiile moderne de server, această funcționalitate este frecvent disponibilă, dar nu trebuie presupusă: se verifică înainte.
Pașii de lucru sunt simpli ca logică. Intri în directorul tracefs, confirmi tracerul disponibil, oprești temporar scrierea în buffer, golești trace, setezi filtrul, alegi function_graph și pornești capturarea pentru scenariul pe care vrei să-l observi. La final, oprești tracingul și citești trace sau folosești trace_pipe dacă vrei flux live. Important: trace_pipe consumă evenimentele pe măsură ce sunt citite, în timp ce trace oferă o vedere statică asupra bufferului.
Cum limitezi zgomotul
Cea mai mare greșeală este să pornești function_graph pe tot kernelul și apoi să te miri că ai prea multă informație. Filtrarea este esențială. Fișierul set_graph_function limitează function_graph la funcțiile indicate și la funcțiile chemate de acestea. available_filter_functions arată ce funcții pot fi folosite în filtru. set_ftrace_filter și set_ftrace_notrace pot influența, de asemenea, ce se urmărește.
În practică, alegi o funcție relevantă pentru problema ta: o cale de sistem de fișiere, un subsistem de rețea, o funcție de driver sau o zonă de kernel pe care o suspectezi. Dacă nu știi de unde să începi, pornești mai larg, dar pe interval scurt, apoi restrângi.
Opțiuni care ajută la citirea latenței
Pentru o captură lizibilă, funcgraph-duration este aproape obligatorie. funcgraph-proc afișează comanda procesului pe fiecare linie, util când aceeași cale de kernel este atinsă de mai multe procese. funcgraph-cpu arată procesorul pe care apare evenimentul. max_graph_depth limitează adâncimea arborelui, astfel încât să nu transformi o suspiciune punctuală într-un raport imposibil de citit.
trace_clock merită atenție când compari evenimente între CPU-uri. Documentația arată că ceasul local este rapid, dar poate să nu fie sincronizat între procesoare; pentru unele analize, global poate fi mai potrivit. Schimbarea ceasului curăță bufferul, deci se face înainte de captură.
Ce trebuie evitat
Nu activa tracing extins pe sisteme de producție fără fereastră de test, filtru și plan de oprire. Documentația avertizează că unele opțiuni, cum ar fi stivele la fiecare funcție, pot degrada serios performanța dacă nu limitezi funcțiile urmărite. function_graph este o unealtă de diagnostic, nu un mod normal de operare.
Nu interpreta o singură captură ca verdict definitiv. O latență poate depinde de încărcare, CPU, I/O, întreruperi, scheduling sau de faptul că procesul a fost scos temporar de pe CPU. Opțiunea sleep-time schimbă modul în care este contabilizat timpul când taskul este programat afară, deci trebuie înțeleasă înainte de concluzii.
Concluzia utilă
function_graph tracer este una dintre cele mai directe metode de a vedea unde se pierde timp în interiorul kernelului Linux, fără rebuild și fără instrumente externe grele. Folosit cu filtre, opțiuni de durată și capturi scurte, poate transforma o latență vagă într-o listă concretă de funcții de analizat. Folosit fără limitare, poate produce zgomot și overhead. Diferența dintre cele două stă în disciplină: verifici tracerul, filtrezi, capturezi scurt, oprești și interpretezi prudent.
