Cum găsești problemele de I/O cu iostat, pidstat, blktrace și metricile PSI din Linux

Un server poate avea CPU liber și suficient RAM, dar aplicațiile să răspundă totuși lent. Cauza poate fi stocarea: cereri care așteaptă în coadă, un proces care scrie agresiv, storage remote lent sau perioade în care workload-ul este efectiv blocat după I/O.

În loc să te uiți doar la %util, investigația corectă merge pe patru niveluri: dispozitiv cu iostat, proces cu pidstat, request-uri block-layer cu blktrace și impactul real asupra workload-ului prin PSI.

Instalează instrumentele

Pe Ubuntu/Debian:

sudo apt update
sudo apt install sysstat blktrace

Pe Fedora/RHEL-like:

sudo dnf install sysstat blktrace

Pachetul sysstat include atât iostat, cât și pidstat; primul raportează activitatea dispozitivelor block, iar al doilea poate atribui I/O proceselor individuale.

Pasul 1: stabilește dacă discul este problema

Pornește cu:

iostat -xz -y 1

-x activează statisticile extinse, -z ascunde dispozitivele inactive, iar -y elimină primul raport bazat pe valorile acumulate de la boot.

Urmărește în special:

r/s, w/s       operații pe secundă
rkB/s, wkB/s   throughput
r_await        latența medie pentru citiri
w_await        latența medie pentru scrieri
aqu-sz         lungimea medie a cozii
%util          timpul în care dispozitivul procesează I/O

await include atât timpul petrecut în coadă, cât și timpul efectiv de servire, iar aqu-sz reprezintă lungimea medie a cozii.

Nu interpreta însă %util=100 drept „SSD-ul este garantat saturat”. Documentația sysstat avertizează că pentru dispozitive capabile de I/O paralel — inclusiv SSD-uri moderne și RAID — această valoare nu reflectă direct limita reală de performanță.

Mai important este dacă await și aqu-sz cresc simultan când aplicația devine lentă.

Pasul 2: găsește procesul care generează I/O

După ce ai confirmat presiunea pe storage:

pidstat -d 1

Pentru toate procesele:

pidstat -d -p ALL 1

Coloanele importante sunt:

kB_rd/s
kB_wr/s
kB_ccwr/s
iodelay

kB_rd/s și kB_wr/s indică volumul de citiri și scrieri atribuit procesului. iodelay reprezintă timpul petrecut în așteptarea I/O block sincron și a operațiunilor de swap-in, exprimat în ticks de ceas.

Dacă suspectezi PostgreSQL:

pidstat -d -C postgres 1

Sau un PID precis:

pidstat -d -p 4281 1

Acum poți diferenția între „discul este lent” și „procesul X generează 400 MB/s de scrieri”.

Pasul 3: verifică dacă workload-ul chiar stă blocat

Kernelul expune Pressure Stall Information în:

cat /proc/pressure/io

Un rezultat arată astfel:

some avg10=7.40 avg60=3.20 avg300=1.11 total=...
full avg10=2.10 avg60=0.80 avg300=0.30 total=...

some reprezintă intervalele în care cel puțin unele task-uri sunt blocate din cauza resursei. full indică perioadele în care toate task-urile non-idle relevante sunt blocate simultan și sistemul nu mai face muncă productivă pentru workload-ul respectiv. Valorile avg10, avg60 și avg300 sunt procente mediate pe 10, 60 și 300 de secunde.

Aici apare diferența dintre un disc „ocupat” și o problemă percepută efectiv de aplicație.

Monitorizează:

watch -n 1 cat /proc/pressure/io

Dacă full avg10 crește în exact momentul în care latența aplicației explodează, ai o dovadă mult mai puternică de contention I/O.

Pasul 4: intră în block layer cu blktrace

Când iostat arată latență, dar încă nu înțelegi comportamentul request-urilor, identifică dispozitivul:

lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS

Pentru o captură scurtă de 15 secunde:

sudo blktrace \
  -d /dev/nvme0n1 \
  -w 15 \
  -o trace

Transformă rezultatul în format lizibil:

sudo blkparse -i trace

Sau pentru analiză live:

sudo blktrace -d /dev/nvme0n1 -o - |
sudo blkparse -i -

blktrace captează evenimentele din block I/O layer — inclusiv operațiuni de queue, issue, complete, read, write și requeue — iar blkparse combină fluxurile provenite de pe CPU-uri și le transformă în output analizabil.

Nu lăsa tracing-ul să ruleze nelimitat pe un server aglomerat. Folosește -w, filtre și o fereastră în care poți reproduce problema.

Corelează cele patru niveluri

Un diagnostic solid poate arăta astfel:

iostat:
w_await crește de la 2 ms la 85 ms
aqu-sz urcă puternic

pidstat:
backup-worker generează majoritatea scrierilor

PSI:
io full avg10 crește la 12%

blktrace:
numeroase write requests se acumulează înainte de completare

Abia acum ai suficiente informații pentru a decide dacă trebuie schimbată programarea backup-ului, limitat un workload, investigat filesystem-ul, verificat device-ul sau mărită performanța storage-ului.

iostat spune ce se întâmplă cu discul, pidstat spune cine generează activitatea, PSI arată cât afectează workload-ul, iar blktrace îți permite să vezi ce se întâmplă efectiv în block layer.

Surse folosite

Linux man-pages / sysstat — iostat, metricile await, aqu-sz și %util.

Linux man-pages / sysstat — pidstat și statisticile I/O per proces.

Linux Kernel Documentation — Pressure Stall Information și /proc/pressure/io.

Linux man-pages — blktrace și blkparse pentru tracing la nivelul block layer.