iostat și iotop: diagnosticarea blocajelor de stocare Linux

Când un server Linux pare lent, stocarea este unul dintre primele locuri în care trebuie să căutați. iostat vă arată dacă discul este suprasolicitat; iotop vă arată care proces cauzează încărcarea. Folosite împreună, ele răspund la cele două întrebări importante: discul este într-adevăr blocajul și, dacă da, ce îl suprasolicită? Acest articol acoperă instalarea, modul de citire a ieșirii (inclusiv unde se află %util pe hardware-ul modern) și un flux de lucru pentru a trece de la simptom la remediere.

Instalarea iostat și iotop

iostat vine împreună cu pachetul sysstat; iotop se livrează separat. Instalați ambele:

# Debian/Ubuntu
sudo apt install sysstat iotop
 
# RHEL, AlmaLinux, Rocky, CentOS Stream
sudo dnf install sysstat iotop
 
# Arch
sudo pacman -S sysstat iotop

Pe Ubuntu, sysstat este livrat dezactivat. Pentru a colecta date de fundal pentru o analiză ulterioară cu sar, editați /etc/default/sysstat, setați ENABLED="true"și reporniți serviciul:

sudo systemctl restart sysstat

iotop trebuie să ruleze ca root. Pe RHEL 9 și versiunile mai noi, contabilizarea întârzierilor este dezactivată în mod implicit, ceea ce lasă IO și SWAPIN goale. Activați-o cu:

echo 1 | sudo tee /proc/sys/kernel/task_delayacct

Adăugați kernel.task_delayacct = 1 la /etc/sysctl.conf pentru a o face să persiste după reporniri.

Citirea ieșirii iostat

Rulați iostat cu statistici extinse și ignorați primul eșantion, care arată doar mediile de la pornire:

iostat -xz 2

Indicatorul -x adaugă statistici extinse, -z ascunde dispozitivele inactive, iar 2 reîmprospătează datele la fiecare două secunde. Coloanele importante:

• await: timpul mediu în milisecunde necesar pentru finalizarea unei solicitări de I/O, inclusiv timpul de așteptare în coadă. Cel mai important număr atunci când utilizatorii se plâng de încetinire.
• r/s și w/s: IOPS de citire și scriere. Combinat cu rkB/s și wkB/s acestea vă indică dacă sarcina de lucru este aleatorie (IOPS ridicat, debit redus) sau secvențială (IOPS redus, debit ridicat).
• aqu-sz: adâncimea medie a cozii. Pentru HDD-uri, orice valoare susținută peste 1 înseamnă că discul nu poate ține pasul.
• %util: procentul de timp în care dispozitivul a avut cel puțin o operațiune I/O în curs. Util pentru HDD-uri, înșelător pentru NVMe (vezi mai jos).

O referință rapidă privind pragurile:

Unde se află %util

%util este indicatorul la care majoritatea oamenilor apelează în primul rând, iar în cazul NVMe acesta este în mod activ înșelător. Kernelul consideră %util „orice operațiune de I/O în curs de desfășurare în orice moment”, ceea ce este în regulă pentru un disc rotativ care procesează o singură solicitare la un moment dat, dar nu are sens pentru dispozitivele NVMe care gestionează mii de solicitări în paralel pe cozile hardware. O unitate NVMe poate sta la 100% %util în timp ce funcționează la 5% din capacitatea sa reală.

Pe NVMe, aveți încredere r_await, w_awaitși aqu-sz în schimb. Dacă r_await rămâne sub 1 ms și adâncimea cozii este cu mult sub adâncimea cozii hardware a dispozitivului (adesea 1024 sau mai mare), unitatea nu este de fapt saturată, indiferent de ce %util spune.

Pentru o vizualizare rapidă a NVMe în MB/s în loc de kB/s:

iostat -xm 1

Pentru colectarea pe termen lung, puteți corela ulterior cu jurnalele aplicației:

iostat -x -t 5 720 > /var/log/iostat.log

Aceasta prelevează eșantioane la fiecare 5 secunde timp de o oră. sar din același pachet sysstat vă oferă date echivalente cu stocare istorică persistentă și este cea mai bună alegere pentru monitorizarea continuă.

Confirmarea cu CPU iowait

Dacă iostat arată o solicitare a stocării, verificați și coloana %iowait coloana din rezumatul CPU din partea de sus a aceleiași ieșiri. %iowait peste 15-20% împreună cu un nivel ridicat await confirmă că blocajul este la stocare. Dacă %iowait este ridicat, dar await pare normal, rulați vmstat 1 și verificați si și so . O activitate de swap diferită de zero înseamnă că sunteți limitat de memorie și că traficul pe disc este paginare, nu I/O al aplicației.

Citirea rezultatelor iotop

Odată ce iostat confirmă un blocaj de stocare, iotop vă indică procesul responsabil. Începeți cu:

sudo iotop -o

Indicatorul -o ascunde procesele inactive, lăsând doar cele care efectuează activ operațiuni de I/O. Coloanele de urmărit:

• DISK READ / DISK WRITE: debitul în timp real per proces. Identifică procesele care consumă resurse în mod evident.
• IO: procentul de timp în care procesul este blocat la I/O. Un proces care scrie doar 50 kB/s poate afișa 99% IO dacă efectuează apeluri sincrone fsync() . Această coloană contează mai mult decât debitul brut.
• SWAPIN: procentul de timp petrecut în așteptare pentru pagini de swap. O valoare diferită de zero aici înseamnă că sistemul utilizează paginarea, iar „problema de stocare” este, de fapt, o problemă de memorie.

Pentru aplicațiile multithread (MySQL, PostgreSQL, sarcini de lucru Java), agregați thread-urile înapoi în procese folosind -Pși adăugați -a pentru a acumula totalurile de la pornirea iotop:

sudo iotop -oPa

Indicatorul -a este trucul pentru a detecta sarcini de lucru intermitente, cum ar fi sarcinile de backup care rulează doar câteva secunde la un moment dat și care altfel ar fi greu de observat într-o vizualizare live.

Pentru înregistrarea nesupravegheată în timpul intervalelor de timp din timpul nopții, când nimeni nu urmărește:

sudo iotop -botqq -d 10 > /var/log/iotop.log

Aceasta scrie o captură de ecran neinteractivă la fiecare 10 secunde. Combinați-o cu marcajele de timp din sarcinile de backup sau cron pentru a identifica vinovatul după ce s-a întâmplat.

Un flux de lucru de diagnosticare

Majoritatea investigațiilor privind I/O-ul discului urmează aceeași cale:

1. iostat -xz 2 pentru a confirma că discul este într-adevăr gâtul de sticlă. Uitați-vă la await, aqu-szși %iowait. Dacă acestea sunt normale, problema nu ține de stocare și ar trebui să căutați cu totul în altă parte.
2. iotop -oPa pentru a găsi procesul care generează încărcarea. Urmăriți mai mult coloana IO decât coloana de transfer. Cele mai mari probleme sunt adesea programele care efectuează multe scrieri sincrone mici, nu cele care transferă cei mai mulți octeți.
3. lsof -p <pid> pentru a vedea ce fișiere accesează procesul respectiv. De obicei, acest lucru identifică imediat tipul de sarcină de lucru: un jurnal de scriere anticipată a bazei de date, un fișier jurnal al aplicației, un punct de montare a copiei de rezervă, un fișier temporar.

Două tipare care merită cunoscute.

Dacă vedeți fire de kernel precum jbd2/... (jurnal ext4) sau txg_sync (ZFS) în partea de sus a listei de scriitori din iotop, acestea răspund la scrieri din partea altor procese, nu le inițiază. Procesul din spațiul utilizator care generează traficul jurnalului este cauza reală; continuați să cercetați.

Pe un VPS, un await cu scăzut %util este semnalul clasic al unui vecin zgomotos. Un alt chiriaș monopolizează spațiul de stocare partajat, iar I/O-ul dvs. se află în coadă pe partea hipervizorului, nu pe discul dvs. virtual. Puteți confirma, dar nu remedia această problemă din interiorul oaspetelui; soluția este fie să escaladați problema către furnizor, fie să vă mutați pe un server cu spațiu de stocare izolat.

Remedierea blocajelor comune de I/O

Odată ce știți ce afectează discul, soluțiile sunt de obicei simple.

Reducerea priorității I/O-ului necritic. ionice plasează un proces în clasa de programare inactivă, unde utilizează lățimea de bandă a discului doar atunci când nimic altceva nu o solicită:

ionice -c 3 -p <pid>
sudo ionice -c 3 rsync -a /data /backup

Prima formă modifică un proces în execuție; a doua lansează unul nou, deja în clasa inactivă. În iotop, puteți modifica prioritatea unui proces în execuție în mod interactiv apăsând tasta i.

Mutați sarcinile de lucru intense pe un spațiu de stocare mai rapid. Dacă iostat arată un disc SATA supraîncărcat de scrieri în baza de date și există un NVMe inactiv în aceeași cutie, mutați directorul de date al bazei de date. Diferența de ordinul de mărime în IOPS face ca aceasta să fie cea mai eficientă soluție disponibilă.

Setați programatorul I/O corect. Kernel-urile moderne au setări implicite rezonabile, dar merită verificat. Pentru NVMe și SSD-uri, setați programatorul la none. Dispozitivul gestionează cozile de așteptare la nivel hardware mai bine decât poate face kernelul:

echo none > /sys/block/nvme0n1/queue/scheduler

Pentru HDD-urile care gestionează sarcini de lucru mixte, mq-deadline este alegerea obișnuită.

Montați cu noatime. Fiecare citire actualizează implicit timestamp-ul ultimei accesări a fișierului, generând o scriere pentru fiecare citire. Pe sistemele de fișiere cu citiri intense, aceasta reprezintă I/O inutil. Adăugați noatime la opțiunile de montare din /etc/fstab:

UUID=... /data ext4 defaults,noatime 0 2

Reglați writeback pentru scrieri în rafale. Pe serverele cu multă memorie RAM, pragurile implicite pentru paginile murdare permit cache-ului de pagini să acumuleze gigabiți de date nescrise, apoi să le golească într-o singură operațiune mare. Reduceți pragurile din /etc/sysctl.conf pentru a remedia această problemă:

vm.dirty_ratio = 10
vm.dirty_background_ratio = 5

De obicei, discul în sine nu este problema. Când iostat arată IOPS ridicate și un debit redus, sarcina de lucru efectuează operațiuni de I/O aleatorii pe date care ar putea fi secvențiale sau execută multe operațiuni mici de scriere care ar putea fi grupate. Analizați aplicația înainte de a da vina pe hardware.

Dacă rulați sarcini de lucru cu consum mare de stocare pe un server unde rețeaua poate depăși viteza discului, serverele dedicate FDC bazate pe NVMe vă oferă spațiul necesar pentru a aplica optimizarea de mai sus în mod productiv.