Время от времени наш сервер Linux LAMP (использующий PHP-FPM, XFS на тонком LVM на HW RAID, Centos8) становится недоступным и перестает отвечать на HTTP(S)-запросы.
С помощью централизованного ведения журнала мы выяснили, что в таких случаях средняя загрузка быстро подскакивает до сотен, в то время как все больше и больше процессов (systemd-journald, процессы php, потоки ядра xfs/dm...) переходят в состояние D. Согласно iostat и pidstat, процессор и диск вообще не загружены, а средняя загрузка колеблется около 170, что довольно странно. Из вывода htop/ps нет ни одного или группы вредоносных процессов, которые могли бы объяснить такое поведение. Это просто стандартные процессы, которые, похоже, сталкиваются с каким-то «препятствием на дороге».
Единственная другая странность с мониторингом диска заключается в том, что во время этих событий перегрузки iostat периодически сообщает о довольно высоком значении w_await для раздела /var (2500-5000 мс, в то время как другие разделы, такие как /var/log, /var/lib/mysql, в основном не превышают 10 мс). Этот раздел должен быть тихим большую часть времени, поэтому неясно, почему iostat сообщает о таком большом значении w_await там.
Единственное решение — выключить и снова включить сервер.
Это происходит на двух серверах одного типа, на других — никогда. Похоже, это какая-то неисправность FS/уровня блоков/контроллера/диска; множество процессов внезапно начинают ждать диск или что-то еще в ядре, но, согласно iotop/iostat, диск не делает многого.
Есть ли способ запросить у Linux kernel FS/block layer/controller драйвера, что именно они делают с хранилищем и от имени какого процесса? Стандартные инструменты, такие как iotop/iostat, сообщают мне только имена активных процессов ввода-вывода и активность разделов диска, но не то, какие процессы обращаются к какому разделу диска и что именно они там делают.
решение1
В таких ситуациях я считаю полезным ограничить количество соединений на более высоких уровнях стека.
Когда больше, скажем, 100активныйПроцессы запущены, они спотыкаются друг о друга. Они соперничают за ресурсы (ЦП и т. д.). Чистый эффект в том, чтовсепроцессы работают медленнее, иногда до такой степени, что кажется, что единственным решением является перезагрузка сервера.
В случае с MariaDB я рекомендую включить slowlog, чтобы вы могли определить запрос, который оказывает наибольшее влияние на систему. Затем ускорьте его. Если вам нужна помощь, предоставьте запрос, его Explain и Create Table. Подробнее: http://mysql.rjweb.org/doc.php/mysql_analysis#slow_queries_and_slowlog
Ускорение нескольких запросов, вероятно, приведет к снижению средней нагрузки 170 и ввода-вывода, тем самым устраняя узкое место.