Pe serverele Linux cu două sau mai multe socketuri CPU, performanța nu depinde doar de câte nuclee ai disponibile. Contează și unde rulează procesul, unde se află memoria pe care o folosește și ce prioritate primește de la scheduler. Trei comenzi utile pentru această analiză sunt numastat, taskset și chrt. Folosite împreună, ele nu „repară” automat un sistem lent, dar îți arată dacă problema seamănă cu acces NUMA ineficient, migrare excesivă între procesoare sau configurare greșită a priorităților.
NUMA, pe scurt, înseamnă Non-Uniform Memory Access. Pe un sistem multi-socket, fiecare procesor are acces mai rapid la memoria locală și mai lent la memoria atașată altui socket. Kernelul Linux încearcă să optimizeze plasarea proceselor și a memoriei, dar aplicațiile mari, bazele de date, motoarele de căutare, workloadurile AI sau procesele real-time pot ajunge să consume multă memorie „remote”. Rezultatul poate fi latență crescută, variații mari de performanță și utilizare CPU aparent normală, dar throughput slab.
Primul instrument de verificat este numastat. Comanda afișează statistici NUMA pe noduri, inclusiv informații despre alocări locale și acces la memorie. Un punct bun de pornire este:
numastat
Pentru procese individuale, pe distribuțiile unde opțiunea este disponibilă, poți folosi:
numastat -p PID
Înlocuiește PID cu identificatorul procesului suspect. Te interesează dacă memoria procesului este concentrată pe nodul pe care rulează firele sale de execuție sau dacă este împrăștiată pe alte noduri. Nu trage concluzii dintr-o singură captură: rulează comanda în momente diferite, mai ales în timpul încărcării reale. Dacă vezi multă memorie pe noduri îndepărtate, acesta este un indiciu, nu un verdict. Confirmă cu top, htop, perf, aplicația monitorizată și metricile de latență.
taskset te ajută să vezi sau să setezi afinitatea CPU a unui proces. Afinitatea spune pe ce procesoare logice are voie să ruleze procesul. Pentru a verifica un proces existent:
taskset -pc PID
Dacă vrei să pornești o comandă limitată la anumite CPU-uri:
taskset -c 0-15 comanda_ta
Pe un sistem multi-socket, trebuie să știi ce CPU-uri aparțin fiecărui nod NUMA. Verifică înainte topologia cu:
lscpu
lscpu -e=CPU,NODE,SOCKET,CORE
Apoi poți testa dacă aplicația se comportă mai stabil când este ținută pe un set de CPU-uri din același nod. Atenție: taskset este util pentru diagnostic și pentru workloaduri controlate, dar poate reduce performanța dacă restrângi prea mult aplicația. De exemplu, o bază de date cu multe fire de execuție poate avea nevoie de mai multe nuclee decât îi permiți. Scopul inițial este să compari: aceeași sarcină fără afinitate, apoi cu afinitate coerentă NUMA.
chrt intră în discuție când suspectezi probleme de scheduling, nu doar de plasare pe CPU. Comanda afișează sau modifică politica și prioritatea de scheduling pentru un proces. Pentru verificare:
chrt -p PID
Pentru politici real-time, cum ar fi FIFO sau RR, este nevoie de privilegii adecvate și de multă prudență. Un proces real-time configurat prost poate înfometa alte procese, inclusiv servicii critice. Ca regulă practică, nu ridica prioritatea în producție doar pentru că o aplicație „pare lentă”. Mai întâi confirmă că latența vine din competiție de scheduling, nu din I/O, lock-uri, memorie remote, swap sau limitări ale aplicației.
Un flux de investigație sigur arată așa. Mai întâi identifici procesul și simptomele: latență, jitter, scădere de throughput, spike-uri. Apoi verifici topologia cu lscpu și observi distribuția NUMA cu numastat. După aceea verifici afinitatea curentă cu taskset -pc PID. Dacă procesul sare pe CPU-uri din noduri diferite în timp ce memoria lui este concentrată pe alt nod, ai un candidat pentru test controlat. Rulezi o probă cu taskset, pe un interval scurt și măsurabil, preferabil în staging sau într-o fereastră de mentenanță. La final verifici chrt -p PID ca să te asiguri că nu există o politică de scheduling neașteptată.
Pentru servicii persistente, nu transforma comenzile manuale în soluție finală fără documentare. În practică, afinitatea CPU și politica de scheduling se configurează mai curat prin systemd, containere, orchestratoare sau fișierele aplicației, în funcție de infrastructură. Pe Kubernetes, de exemplu, trebuie analizate și CPU Manager, requesturile, limiturile și pinningul oferit de platformă. Pe servere bare-metal, documentează exact CPU-urile, nodurile NUMA și motivul setării.
Cele mai frecvente greșeli sunt trei: interpretarea izolată a numastat, pinning agresiv cu taskset și folosirea chrt ca „accelerator”. numastat indică unde se alocă memoria, dar nu explică singur cauza. taskset poate ajuta localitatea, dar poate crea blocaje dacă aplicația are nevoie de paralelism. chrt poate reduce jitterul pentru procese legitime real-time, dar poate deteriora stabilitatea sistemului dacă este folosit fără limite.
Concluzia practică: numastat îți arată semnele NUMA, taskset îți permite teste controlate de afinitate CPU, iar chrt îți verifică politica de scheduling. Împreună formează un set defensiv de diagnostic pentru administratori Linux care investighează performanța pe sisteme multi-socket. Folosește-le cu măsurători înainte și după, nu ca rețete universale.
