Aceasta e o versiune anterioară a paginii.
Performanța serverului Linux: Disk I/O îți blochează aplicația?
Dacă serverul tău Linux este încetinit de disk I/O, primul pas este de obicei să rulezi comanda top în terminal pentru a verifica load averages. Există însă situații în care top afișează load averages foarte mari chiar și cu CPU 'us' (user) scăzut și CPU 'id' (idle) ridicat.
Acesta este exact cazul descris mai jos: load averages depășesc 30 pe un server cu 24 de core-uri, dar CPU-ul arată circa 70% idle. Una dintre cauzele frecvente ale acestei situații este un bottleneck de disk I/O.
Ce este I/O wait bottleneck?
Storage I/O reprezintă operațiunile de input/output (scriere/citire) pe un dispozitiv de stocare - fie că este un disk spinning, un SSD sau un NVMe. Cererile care implică disk I/O pot fi încetinite dramatic dacă CPU-urile trebuie să aștepte ca disk-ul să citească sau să scrie date.
I/O Wait este procentul de timp în care un CPU a stat inactiv în timp ce cel puțin o cerere I/O era încă în așteptare. Tocmai de aceea 'wa' scade când CPU-ul devine ocupat, chiar dacă storage-ul este la fel de lent ca înainte.
Comanda TOP: load averages și wa (wait time)
Când intri în top, primul lucru de verificat sunt load averages (colțul dreapta sus). O valoare foarte mare indică o acumulare de cereri. Apoi urmărești liniile de CPU și memorie, împreună cu coloanele %CPU și %MEM.
Valoarea importantă de urmărit este 'wa' (wait). Pe un server sănătos, aceasta se menține aproape de zero - spike-uri scurte în timpul unui backup sau rotații de loguri sunt normale. Ce trebuie să identifici este o valoare consistent ridicată, ceea ce sugerează că dispozitivul de stocare nu reușește să țină pasul cu cererile primite.
top pentru a vizualiza 'wa' per fiecare core CPU în parte. Valoarea medie poate fi înșelătoare - unele core-uri pot avea wa de 60% chiar dacă media pare acceptabilă.
Pentru a lista procesele blocate în uninterruptible sleep (starea D):
ps -eo state,pid,comm | grep "^D"
Dacă aceleași PID-uri apar constant în starea D, înseamnă că procesele respective sunt blocate în kernel așteptând storage-ul.
iostat: măsurarea latenței de disk
top și 'wa' îți spun că ceva blochează - nu și care dispozitiv sau dacă disk-ul este cu adevărat lent. Comanda iostat răspunde la ambele întrebări. Face parte din pachetul sysstat:
iostat -xz 1
- -x - statistici extinse
- -z - ascunde dispozitivele idle
- 1 - refresh la fiecare secundă
Cele mai relevante coloane:
| Coloană | Semnificație |
|---|---|
| r_await | Milisecunde medii de așteptare pentru o citire (inclusiv timpul în coadă) |
| w_await | Milisecunde medii de așteptare pentru o scriere (inclusiv timpul în coadă) |
| %util | Procentul intervalului în care dispozitivul a avut cel puțin o cerere în curs |
ATOP: monitorizarea DSK (storage) I/O
Cu atop poți vedea dacă dispozitivul de stocare este 90-100% ocupat - un semn clar de bottleneck sever. Cererile sunt blocate până când disk I/O reușește să recupereze.
În timp ce ești în atop, apasă 'd' pentru a vizualiza procesele și PID-urile care folosesc disk I/O.
Procese de urmărit:
- flush-8:0 (sau
kworker/u8:2+flush-8:0pe kernel-uri mai noi) - thread-ul kernel de writeback care trimite page cache-ul dirty pe block device - jbd2/sda5-8 - thread-ul de journaling ext4 pentru
/dev/sda5
Ambele sunt simptome, nu cauza problemei - apar active din cauza a ceea ce aplicațiile de deasupra scriu (fișiere cache, loguri).
IOTOP: insight în timp real pe read/write
iotop monitorizează informațiile de utilizare I/O raportate de kernel-ul Linux și afișează un tabel al utilizării curente per proces sau thread.
Comandă recomandată:
iotop -oPa
| Opțiune | Efect |
|---|---|
| -o (–only) | Afișează doar procesele care fac efectiv I/O |
| -P (–processes) | Afișează procese, nu thread-uri individuale |
| -a (–accumulated) | Afișează totalul I/O de la pornirea iotop, nu bandwidth-ul curent |
iotop pornește cu toate coloanele pe zero sau afișează un avertisment despre delay accounting, activează-l:sudo sysctl kernel.task_delayacct=1
Această setare se pierde la reboot. Pentru a o face permanentă, adaugă delayacct la opțiunile de boot ale kernel-ului.
Majoritatea distribuțiilor livrează acum iotop-c, o rescrie în C a tool-ului original Python, cu aceleași opțiuni.
Verificarea rapidă: /proc/pressure/io
Kernel-urile moderne pot raporta direct presiunea I/O prin PSI (Pressure Stall Information), disponibil din kernel 4.20:
cat /proc/pressure/io
Exemplu de output pe un server cu probleme:
some avg10=44.21 avg60=39.07 avg300=31.88 total=8814592211 full avg10=38.90 avg60=35.62 avg300=29.15 total=7913804412
| Linie | Semnificație |
|---|---|
| some | Procentul din ultimele 10/60/300 secunde în care cel puțin un task a fost blocat așteptând I/O |
| full | Procentul în care toate task-urile non-idle au fost blocate - aceasta urmărește un site care devine iresponsiv |
Valori susținute de două cifre pe linia full indică o problemă serioasă - același semnal ca 60% 'wa' în top, dar dintr-o singură comandă.
psi=1 pe linia de comandă a kernel-ului.
Benchmark rapid cu dd
Când numerele indică hardware-ul ca problemă, benchmarkează-l înainte să deschizi un ticket la provider:
dd if=/dev/zero of=diskbench bs=1M count=1024 conv=fdatasync
dd răspunde la o singură întrebare: poate dispozitivul să scrie un singur stream secvențial mare la o viteză rezonabilă? Nu oferă informații despre IOPS sau latență sub concurență. Pentru aceste măsurători, folosește fio.
Un provider va argumenta cu opinia ta - este mult mai greu să argumentezi cu 23.3 MB/s.
Ordinea de investigare (rezumat)
- Verifică load averages și 'wa' în
top - Apasă '1' pentru a extinde per core
- Confirmă la nivel de dispozitiv cu
iostat -xz 1sau/proc/pressure/io - Identifică procesele responsabile cu
atopșiiotop
Sărind pasul de confirmare la nivel de dispozitiv riști să ajungi la concluzii greșite - de exemplu, să dai vina pe MySQL pentru o problemă de storage.