Când un server Linux pare „ocupat”, dar CPU-ul nu explică totul, problema poate fi mai subtilă: firele de execuție nu muncesc în paralel, ci așteaptă unele după altele la același lock. În astfel de cazuri, optimizarea nu începe cu mai multe core-uri sau cu schimbarea hardware-ului, ci cu o întrebare simplă: ce mutex, spinlock sau alt mecanism de sincronizare serializează workload-ul?
În Linux, perf lock este una dintre uneltele specializate pentru această investigație. Face parte din familia perf și este conceput pentru analiza evenimentelor de lock din kernel. Nu este o soluție universală pentru orice blocaj din aplicație, dar poate arăta foarte clar unde apar contended locks, cât se așteaptă, ce fire sunt afectate și ce tipuri de lock-uri merită investigate.
Primul pas: confirmă că problema chiar arată ca lock contention
Lock contention apare când mai multe fire încearcă să acceseze aceeași resursă protejată de un lock, iar unele trebuie să aștepte. Simptomele pot fi înșelătoare: latență crescută, throughput plafonat, CPU aparent folosit inegal, multe thread-uri active dar progres redus.
Înainte să tragi concluzia că „aplicația e lentă”, verifică dacă workload-ul are multe fire, dacă performanța nu mai crește când adaugi core-uri și dacă latența crește în zone cu acces concurent la aceleași structuri de date, fișiere, socket-uri sau subsisteme kernel.
Comanda de bază este simplă ca idee: rulezi workload-ul sub observație, apoi citești raportul. În forma clasică, perf lock record rulează comanda urmărită și salvează evenimentele într-un fișier perf.data. Apoi, perf lock report afișează statistici despre lock-uri. Documentația perf lock descrie și comenzile script, info și contention, ultima fiind orientată direct spre statistici de contended locks.
Ce urmărești în raport
Cele mai utile coloane nu sunt neapărat cele cu cele mai multe achiziții ale unui lock. Un lock folosit des nu este automat o problemă. Important este cât de des produce așteptare și cât timp se pierde acolo.
În perf lock report, cheile de sortare includ acquired, contended, avg_wait, wait_total, wait_max și wait_min. Pentru investigații reale, wait_total și avg_wait sunt adesea mai relevante decât simplul număr de achiziții. Un lock care blochează rar, dar produce așteptări foarte lungi, poate afecta latența. Un lock care blochează des, dar scurt, poate limita throughput-ul.
perf lock contention merge și mai direct spre această întrebare. Documentația menționează sortarea după contended, wait_total, wait_max, wait_min și avg_wait. Tot acolo apar opțiuni utile pentru analiză: -t pentru statistici pe thread, -a pentru colectare la nivel de sistem, -p pentru un proces existent, -C pentru anumite CPU-uri și -E pentru limitarea numărului de intrări afișate.
Filtrarea face diferența
Pe sisteme mari, raportul brut poate fi zgomotos. De aceea, perf lock contention permite filtre după tipul lock-ului. Opțiunea –type-filter poate restrânge analiza la tipuri precum spinlock, mutex, rwlock, rwsem, semaphore sau rtmutex. Pentru un workload unde suspectezi competiție pe spinlock-uri, filtrarea după spinlock reduce mult zgomotul. Pentru zone unde firele dorm în așteptarea unei resurse, mutex sau rwsem pot fi mai relevante.
Opțiunea –lock-filter poate restrânge analiza după nume sau adresă de lock, iar –callstack-filter afișează doar cazurile în care call stack-ul conține un anumit șir. Acest lucru ajută când ai deja o ipoteză: un subsistem, o funcție sau o cale de cod care apare constant în profilare.
Atenție însă la interpretare. Un spinlock contended indică de obicei așteptare activă și presiune pe CPU. Un mutex sau un rwsem contended poate indica fire care se blochează până când resursa devine disponibilă. În ambele cazuri, problema nu este doar „lock-ul există”, ci faptul că secțiunea critică este prea aglomerată, prea lungă sau apelată prea des.
Limitări importante
perf lock este foarte util pentru lock-uri din kernel, dar nu trebuie prezentat ca lupă magică pentru toate mutex-urile din user space. Pentru aplicații care folosesc pthread mutex, Java monitors, Go runtime locks sau alte mecanisme interne, analiza trebuie corelată cu alte instrumente: profilare off-CPU, tracepoints, eBPF, loguri ale aplicației sau instrumentele runtime-ului respectiv.
De asemenea, colectarea poate necesita privilegii adecvate, simboluri kernel utile și suport disponibil în kernelul distribuției. Documentația kernelului despre lock statistics arată că Linux poate colecta statistici despre contentions, timp minim, maxim, total și mediu de așteptare, dar unele funcții depind de configurarea kernelului, cum este CONFIG_LOCK_STAT pentru interfața /proc/lock_stat.
Cum transformi raportul în acțiune
Dacă raportul arată un lock cu wait_total mare, nu începe prin a „elimina lock-ul”. Întreabă ce protejează. Poate secțiunea critică face prea multă muncă. Poate un lock global ar trebui împărțit pe mai multe structuri. Poate citirile pot folosi o strategie diferită. Poate problema reală este un model de acces care pune toate thread-urile pe aceeași resursă.
Pentru echipele care administrează servere Linux, perf lock este valoros tocmai pentru că mută discuția de la impresii la dovezi. Nu spune doar că workload-ul „se blochează”, ci arată unde se acumulează așteptarea. Iar în optimizarea de performanță, acesta este pasul esențial: să găsești punctul exact în care paralelismul promis de sistem devine, în practică, execuție pe rând.
