Pressure Stall Information, prescurtat PSI, este una dintre cele mai utile facilități moderne din kernelul Linux pentru a înțelege nu doar cât de ocupat este un server, ci cât timp pierde efectiv munca utilă din cauza lipsei de CPU, memorie sau I/O. Documentația oficială a kernelului descrie PSI ca mecanismul care identifică și cuantifică perturbările produse de contendența pe resurse, adică exact momentele în care workload-urile suferă latențe, pierderi de throughput sau intră în reclaim agresiv. Pentru administratori, asta schimbă întrebarea din „cât de mare este utilizarea?” în „cât de afectată este aplicația?”.
În Linux, PSI este expus prin fișierele din /proc/pressure/: cpu, memory și io. În medii cu cgroup v2, aceleași informații apar și per grup de procese, prin cpu.pressure, memory.pressure și io.pressure. Asta este important în 2026, când multe servere rulează containere, workload-uri mixte sau servicii izolate prin cgroup-uri: poți vedea dacă presiunea este globală sau creată de un singur serviciu.
Formatul este intenționat simplu. Fiecare resursă expune, de regulă, două linii: some și full, împreună cu valorile avg10, avg60, avg300 și total. „Some” arată procentul de timp în care cel puțin unele taskuri au fost blocate sau întârziate de lipsa resursei respective. „Full” arată procentul de timp în care toate taskurile non-idle au fost blocate simultan. Pentru memorie și I/O, „full” este semnalul cel mai valoros când cauți thrashing sau blocaje severe. Pentru CPU, documentația kernelului precizează că „cpu full” este nedefinit la nivel de sistem și, din motive de compatibilitate, este raportat cu zero începând cu kernelul 5.13. Câmpul total este timpul absolut acumulat de stall, în microsecunde, util pentru comparații pe ferestre proprii și pentru detectarea vârfurilor scurte care nu schimbă mult mediile.
Interpretarea corectă cere context. Un avg10 crescut, dar cu avg60 și avg300 joase, indică un episod recent. Dacă și avg60 sau avg300 urcă, problema este deja persistentă. Presiunea pe CPU spune că taskurile sunt gata să ruleze, dar așteaptă timp de procesor; nu este același lucru cu un CPU „plin” în sens clasic. Presiunea pe memorie indică timp pierdut în reclaim, compactare sau alte efecte ale lipsei de RAM, iar aici creșterea valorilor full este un semn că sistemul intră într-o zonă nesănătoasă. Presiunea pe I/O arată cât timp se pierde așteptând acces la stocare; dacă avg10 și total cresc în paralel cu latențe la disc, ai un indiciu solid că bottleneck-ul nu este în aplicație, ci în subsistemul de stocare.
Din perspectivă defensivă, PSI este excelent pentru observabilitate și troubleshooting deoarece leagă simptomele aplicației de impactul real al resurselor. Dacă un serviciu răspunde lent, dar CPU utilization nu pare alarmant, un cpu some ridicat poate confirma competiția pe scheduling. Dacă apar time-out-uri și swap-ul nu este neapărat masiv, memory some și memory full pot arăta că paginarea și reclaim-ul afectează deja latența. În platforme multi-tenant, fișierele de presiune per cgroup ajută la identificarea unui „noisy neighbor” fără să acuzi imediat întregul host.
Pentru capacity planning, PSI este mai util decât un prag fix de utilizare. Un server poate rula mult timp la utilizare mare, dar cu presiune mică, ceea ce sugerează că mai are spațiu operațional. Invers, un host cu utilizare aparent moderată, dar cu memory full sau io full repetat, semnalează că resursele sunt dimensionate prea strâns pentru profilul real al workload-ului. O practică sigură este să construiești baseline-uri pe intervale normale de funcționare, să urmărești separat avg10 pentru incidente rapide și avg60/avg300 pentru tendințe și să corelezi PSI cu metrici clasice precum load average, latența la disc, erorile aplicației și evenimentele OOM. În plus, kernelul permite și monitorizarea pe praguri, iar unele builduri pot porni cu PSI dezactivat implicit prin CONFIG_PSI_DEFAULT_DISABLED, caz în care documentația kernelului arată că activarea se poate face prin parametrul de boot psi=1. Pe scurt, PSI nu înlocuiește restul telemetriei, dar oferă exact stratul care lipsea: costul real, în timp pierdut, al presiunii pe CPU, memorie și I/O.
