Cum se interoghează nucleul Linux care operațiuni legate de stocare sunt executate în prezent la nivelul FS / strat de bloc / controler SATA?

Din când în când, serverul nostru Linux LAMP (folosind PHP-FPM, XFS pe LVM subțire pe HW RAID, Centos8) devine inaccesibil și nu mai răspunde la solicitările HTTP(S).

Prin înregistrarea centralizată am aflat că în acele cazuri, încărcarea medie ajunge rapid la sute, în timp ce tot mai multe procese (systemd-journald, procese php, fire de execuție xfs/dm kernel...) intră într-o stare D. Conform iostat și pidstat, procesorul și discul nu sunt încărcate deloc, în timp ce media de încărcare se situează în jurul valorii de 170, ceea ce este destul de ciudat. De la ieșirea htop/ps, nu există un singur proces sau un grup de procese necinstite care să explice acest comportament. Sunt doar procese standard care par să întâmpine un fel de „blocare rutieră”.

Singurul lucru ciudat cu monitorizarea discului este că, în timpul acelor evenimente de supraîncărcare, iostat raportează intermitent w_wait destul de mare pentru partiția /var (2500-5000ms, în timp ce alte partiții precum /var/log, /var/lib/mysql nu trec de cele mai multe ori peste). 10 ms). Această partiție ar trebui să fie silențioasă de cele mai multe ori, așa că nu este clar de ce iostat raportează timpi de așteptare atât de mari acolo.

Singura soluție este atunci să porniți serverul.

Acest lucru se întâmplă pe două servere de același fel, niciodată pe altele. Se pare că este un fel de defecțiune FS/bloc strat/controller/disc; o mulțime de procese încep brusc să aștepte disc sau altceva în kernel, dar conform iotop/iostat, discul nu face mare lucru.

Există o modalitate de a interoga kernel-ul Linux FS/block layer/controller driver ce fac exact cu stocarea și în numele cărui proces? Instrumentele standard precum iotop/iostat îmi spun doar numele proceselor active I/O și ale activității partițiilor de disc, dar nu și care procese accesează ce partiție de disc și ce fac ele acolo.

În astfel de situații, constat că ajută la accelerarea numărului de conexiuni mai sus în stivă.

Când mai mult de, să zicem, 100 activ procesele rulează, se poticnesc unul de celălalt. Se luptă pentru resurse (CPU, etc). Efectul net este că toate procesele rulează mai lent, uneori până la punctul în care simțiți că singura soluție este să reporniți serverul.

În cazul MariaDB, vă recomand să activați slowlog-ul, astfel încât să puteți identifica interogarea care are cel mai mare impact asupra sistemului. Apoi accelerează-l. Dacă doriți ajutor, furnizați interogarea, explicați și creați tabelul acesteia. Mai mult: http://mysql.rjweb.org/doc.php/mysql_analysis#slow_queries_and_slowlog

Accelerarea câtorva interogări va scădea probabil 170 Load Average și I/O, atenuând astfel blocajul.