Как диагностировать зависание php-fpm процессов?

На VPS стоит Ubuntu 18, nginx, mysql, redis, php7.2-fpm крутится веб-приложение на Laravel. Давно и нормально.
Вдруг сегодня процессы php-fpm выпали в статус "D" (uninterruptible sleep (usually IO)) и по kill -9 не убиваются.
Варианты либо ждать не понятно, чего. Либо reboot.

Первый раз sudo systemctl reboot перезагрузил сервер.
Второй раз не смог за несколько минут. Пришлось через панель хостинга Power cycle запускать.

Три раза уже возникала такая ситуация, требующая reboot сегодня. Никогда такого не было, и вот опять.

В похожем вопросе на SO выяснили, что у них причиной был исполняемый код, связанные с обновлением кэша, параллельно запускавшийся во всех инстансах php-fpm.

В логах не нашёл ничего подозрительного-необычного перед очередными зависаниями. Приложением активно пользуются, по несколько запросов в секунду бывает, но всё как всегда.

Смотрел логи nginx, php-fpm и Laravel-приложения.

php-fpm, по мере выпадения в осадок воркеров, запускал новые, пока не упирался в лимит:
[12-Oct-2019 14:26:07] WARNING: [pool www] server reached pm.max_children setting (8), consider raising it

nginx перед проблемой или уже в её результате начинал сообщать про timeout:
[error] 1053#1053: *13891 upstream timed out (110: Connection timed out) while reading response header from upstream

dmesg пишет про непонятный jbd2/sda-8 и сразу за этим тоже про php-fpm:
484.254707] INFO: task jbd2/sda-8:1540 blocked for more than 120 seconds.
[  484.262192]       Not tainted 4.15.0-65-generic #74-Ubuntu
[  484.272558] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  484.280122] jbd2/sda-8      D    0  1540      2 0x80000000
...
[  484.280256] INFO: task php-fpm7.2:1584 blocked for more than 120 seconds.
[  484.286958]       Not tainted 4.15.0-65-generic #74-Ubuntu
[  484.292249] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  484.305238] php-fpm7.2      D    0  1584    858 0x00000000


VPS (droplet) на DigitalOcean, к ней подключён block storage Volume – как dev/sda. Первая запись в dmesg про него? Из-за этого подключенного volume происходит затык? Как можно его try-catch?

Что смотреть, как понять причину возникновения ситуации?

Upd. техподдержка ответила, что проблема была в физическом оборудовании сервера, где находился инстанс. Они всё починили, проблема исчезла. Заодно перенесли дроплет на другое физ. оборудование на всякий случай. Вопрос снят. Очень хороший ответ Роман Мирр помог разобраться, спасибо!
  • Вопрос задан
  • 1130 просмотров
Решения вопроса 1
2ord
@2ord
jbd2 это подсистема, работающая с ext4.
Похоже что высокая активность I/O.
Чтобы узнать подробнее, нужно иметь историю событий. Программа atop умеет вести учет процессов и ресурсов, позволяя позже проиграть историю, выяснив причину проблемы.
https://haydenjames.io/use-atop-linux-server-perfo...
https://haydenjames.io/linux-server-performance-di...
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы