Как диагностировать прерывистые ошибки uwsgi?
Прежде всего позвольте мне кратко описать нашу установку, прежде чем я задам правильный вопрос:
У нас есть сервер веб-приложений (виртуальная машина), на котором запущено приложение django. Сначала nginx, под ним работает uwsgi, затем оболочка для новых реликвий, за которой следуют django и др., база данных - это отдельный сервер postgresql, расположенный через smartstack (synapse/nerve)
Проблема, с которой мы сталкиваемся, заключается в том, что время от времени (случалось 2 недели назад и дважды за последние 2 дня) один или два рабочих процесса uwsgi отключаются и начинают выдавать "django.db.utils.InterfaceError: соединение уже закрыто" по большинству их запросов.
слегка отредактированная трассировка стека (user и application_name):
Traceback (most recent call last):
File "/home/user/webapps/application_name/local/lib/python2.7/site-packages/newrelic-2.8.0.7/newrelic/api/web_transaction.py", line 863, in __call__
File "/home/user/webapps/application_name/local/lib/python2.7/site-packages/newrelic-2.8.0.7/newrelic/api/function_trace.py", line 90, in literal_wrapper
File "/home/user/webapps/application_name/local/lib/python2.7/site-packages/newrelic-2.8.0.7/newrelic/api/web_transaction.py", line 752, in __call__
File "/home/user/webapps/application_name/local/lib/python2.7/site-packages/django/core/handlers/wsgi.py", line 194, in __call__
signals.request_started.send(sender=self.__class__)
File "/home/user/webapps/application_name/local/lib/python2.7/site-packages/django/dispatch/dispatcher.py", line 185, in send
response = receiver(signal=self, sender=sender, **named)
File "/home/user/webapps/application_name/local/lib/python2.7/site-packages/django/db/__init__.py", line 91, in close_old_connections
conn.abort()
File "/home/user/webapps/application_name/local/lib/python2.7/site-packages/django/db/backends/__init__.py", line 374, in abort
self.rollback()
File "/home/user/webapps/application_name/local/lib/python2.7/site-packages/django/db/backends/__init__.py", line 177, in rollback
self._rollback()
File "/home/user/webapps/application_name/local/lib/python2.7/site-packages/django/db/backends/__init__.py", line 141, in _rollback
return self.connection.rollback()
File "/home/user/webapps/application_name/local/lib/python2.7/site-packages/django/db/utils.py", line 99, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "/home/user/webapps/application_name/local/lib/python2.7/site-packages/django/db/backends/__init__.py", line 141, in _rollback
return self.connection.rollback()
File "/home/user/webapps/application_name/local/lib/python2.7/site-packages/newrelic-2.8.0.7/newrelic/hooks/database_dbapi2.py", line 82, in rollback
django.db.utils.InterfaceError: connection already closed
Трассировка стека никогда не попадает в наше приложение, она касается только новой реликвии и django. Как только рабочий отключается, он не восстанавливается, и все дальнейшие запросы приводят к 500 в журналах uwsgi и 502 в передней части. Я предполагаю, что соединение с базой данных в порядке, потому что работающие с ней братья и сестры продолжают нормально работать, и перезапуск uwsgi мгновенно решает проблему.
Мой вопрос заключается в том, как можно было бы диагностировать эту проблему, чтобы точно определить основную причину, я проверил все, что я знаю, как проверить (память, процессор, журналы, подключение к базе данных) и некоторые вещи, которые я не до конца понимаю, но пытаюсь прочитать вверх (в основном файловые дескрипторы).
Сейчас я обновил новую реликвию (трассировка стека - более старая версия), так как это единственное, что я чувствовал, что мог сделать.
Буду признателен за любые отзывы, многие поиски в Google оказались бесплодными.
ответы могут быть немного задержаны, мой часовой пояс говорит, что пришло время спать. Кроме того, извиняюсь, если это должно быть из-за сбоя сервера или чего-то еще, я просто подумал, что это ближе к проблеме отладки приложения, чем к проблеме конфигурации сервера.