Как диагностировать ошибку тайм-аута в приложении-демоне mod_wsgi? - PullRequest
0 голосов
/ 03 марта 2020

в журналах ошибок Apache моего приложения Flask intr anet Я часто вижу подобные ошибки:

Timeout when reading response headers from daemon process 'dham': /var/www/wsgi/dham.wsgi

«Часто» означает один раз в один или два дня, что соответствует возможно один раз каждые 300 использует. Насколько я понимаю, это происходит, когда приложение WSGI застревает где-то и Apache теряет терпение и убивает демона mod_wsgi. У меня вопрос: как я могу узнать, что приложение делало, когда оно было убито?

Скорее всего, это был запрос к базе данных. Само мое приложение не выполняет никаких длительных запросов, но оно подключается к полудюжине баз данных, которые используются множеством других приложений. Некоторые из них находятся на сервере MySQL на том же хосте (которым я управляю), некоторые - базы данных MS SQL, полностью находящиеся вне моего контроля. Возможно ли, что другой сложный или плохо сформированный запрос приводит к зависанию сервера БД до такой степени, что «мой» запрос застревает? Даже если это только «выбор»; то есть, не пытается записать материал в таблицу, потенциально заблокированную кем-то другим?

Я посмотрел /var/log/mariadb/slow.log. Некоторые (не из моего приложения) занимали до 5 секунд (с временем блокировки менее миллисекунды), но их временные метки не соответствуют блокировке моего приложения.

В настоящее время я пытаюсь добавить тайм-ауты к моим запросам БД, но документы SQLAlchemy очень скудны о том, как это сделать. Я хочу спровоцировать исключение с использованием дампа стека в моем приложении до того, как Apache убьет демона WSGI.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...