====== 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.

[[https://linuxblog.io/what-is-linux-iowait/|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.

<note tip>
Apasă **'1'** în ''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ă.
</note>

Pentru a lista procesele blocate în uninterruptible sleep (starea D):

<code bash>
ps -eo state,pid,comm | grep "^D"
</code>

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 [[https://sysstat.github.io/|sysstat]]:

<code bash>
iostat -xz 1
</code>

  * **-x** - statistici extinse
  * **-z** - ascunde dispozitivele idle
  * **1** - refresh la fiecare secundă

<note warning>
Ignoră primul raport - acesta face media de la boot și poate masca o problemă apărută recent.
</note>

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 |

<note important>
**%util** poate induce în eroare pe SSD și NVMe, care procesează cereri în paralel. Un NVMe poate fi la 100% util și totuși să aibă capacitate disponibilă. Bazează-te pe **r_await** și **w_await** - pe un SSD SATA sănătos, acestea sunt în cifre simple (ms).
</note>

===== 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:0'' pe 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ă:

<code bash>
iotop -oPa
</code>

^ 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 |

<note>
Dacă ''iotop'' pornește cu toate coloanele pe zero sau afișează un avertisment despre delay accounting, activează-l:

<code bash>
sudo sysctl kernel.task_delayacct=1
</code>

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 [[https://github.com/Tomas-M/iotop|iotop-c]], o rescrie în C a tool-ului original Python, cu aceleași opțiuni.
</note>

===== Verificarea rapidă: /proc/pressure/io =====

Kernel-urile moderne pot raporta direct presiunea I/O prin PSI (Pressure Stall Information), disponibil din kernel 4.20:

<code bash>
cat /proc/pressure/io
</code>

Exemplu de output pe un server cu probleme:

<code>
some avg10=44.21 avg60=39.07 avg300=31.88 total=8814592211
full avg10=38.90 avg60=35.62 avg300=29.15 total=7913804412
</code>

^ 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ă.

<note>
Unele distribuții livrează PSI dezactivat. Activează-l adăugând ''psi=1'' pe linia de comandă a kernel-ului.
</note>

===== Benchmark rapid cu dd =====

Când numerele indică hardware-ul ca problemă, benchmarkează-l înainte să deschizi un ticket la provider:

<code bash>
dd if=/dev/zero of=diskbench bs=1M count=1024 conv=fdatasync
</code>

<note important>
''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 [[https://fio.readthedocs.io/en/latest/fio_doc.html|fio]].
</note>

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 1'' sau ''/proc/pressure/io''
  - Identifică procesele responsabile cu ''atop'' și ''iotop''

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.

{{tag>linux performance sysadmin server monitoring}}