Django production (используется gunicorn) - внутренняя ошибка сервера (нет запроса), пока не будет сделано 10-20 запросов

У меня есть производственная система, которая работает уже 2+ года, регулярно (ежедневно/еженедельно) обновляется. Около 2 месяцев назад появилось странное поведение: каждый раз, когда я перезапускаю Gunicorn, на первые 10-20 запросов к веб-серверу я получаю внутреннюю ошибку сервера. Все ошибки (когда система переключена на debug=True) связаны с тем, что запрос был None.

Страница входа (allauth) работает отлично, но как только я ввожу данные своей учетной записи (или любой другой), я получаю внутреннюю ошибку сервера на следующем URL. Если я перезагружу страницу, она загружается нормально. Если я просматриваю сайт, я получаю смесь (полуслучайную) страниц, которые либо загружаются, либо выдают внутреннюю ошибку сервера. После примерно 10-20 попыток загрузки страницы - все начинает работать на 100% AOK. Никаких проблем.

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

Такое впечатление, что что-то не работает в промежуточном ПО или происходит какой-то внутренний тайм-аут, прежде чем данные запроса могут быть сохранены. Но сервер базы данных полностью готов к работе, никаких проблем с нагрузкой нет.

Есть мысли по поводу проблемы или как я могу ее решить. До этого я мог обновлять рабочие серверы без каких-либо простоев, но теперь это вызывает около 4-5 минут простоя каждый раз, когда я хочу обновить код.

Дополнительная информация - нет проблем при локальном запуске runserver и т.д...

Заранее спасибо

Спасибо за ваше время и извините, что не включили больше информации в первоначальное сообщение.

Выяснилось, что я использовал --preload в нашей конфигурации Gunicorn. Это прекрасно работало в течение почти 3 лет в производстве, но, похоже, что это заставляло каждого "рабочего" требовать по крайней мере 2 запроса к нему, прежде чем он начнет их обрабатывать. Странно, да?

Мне нужно было подождать до этих выходных, так как у нас было запланированное время простоя, и я мог изолировать Production, попробовать его с Debug и т.д.

Потом я случайно попробовал убрать опцию --preload и все заработало точно так же, как и раньше, примерно 3 месяца назад.

Увеличение памяти не является проблемой - поэтому я буду двигаться вперед с этим.

Трассировка стека во время отладки, которую я получил, была следующей:

Операционная ошибка в /company/person_overview/ Ошибка SSL SYSCALL: Обнаружено EOF Метод запроса: GET URL запроса: https://www.mowida.com/company/person_overview/. Версия Django: 3.2.15 Тип исключения: OperationalError Значение исключения:
Ошибка SSL SYSCALL: Обнаружено EOF Местоположение исключения: /home/timothy/.pyenv/versions/3.9.13/envs/mwp/lib/python3.9/site-packages/django/db/backends/utils.py, строка 84, in _execute Python Executable: /home/timothy/.pyenv/versions/3.9.13/envs/mwp/bin/python3.9 Версия Python: 3.9.13 Python Path:
['/home/timothy/.virtualenvs/mwp/lib/python3.9/site-packages', '/mwp/mwp', '/home/timothy/.pyenv/versions/3.9.13/envs/mwp/bin', '/home/timothy/.pyenv/versions/3.9.13/lib/python39.zip', '/home/timothy/.pyenv/versions/3.9.13/lib/python3.9', '/home/timothy/.pyenv/versions/3.9.13/lib/python3.9/lib-dynload', '/home/timothy/.pyenv/versions/3.9.13/envs/mwp/lib/python3.9/site-packages', '/mwp/mwp/mwp']. Время сервера: Sat, 13 Aug 2022 22:52:37 +0200

Отслеживание Переход к представлению копирования и вставки /home/timothy/.pyenv/versions/3.9.13/envs/mwp/lib/python3.9/site-packages/django/db/backends/utils.py, строка 84, in _execute return self.cursor.execute(sql, params) ... ▶ Локальные переменные Приведенное выше исключение (ошибка SSL SYSCALL: обнаружено EOF ) было непосредственной причиной следующего исключения: /home/timothy/.pyenv/versions/3.9.13/envs/mwp/lib/python3.9/site-packages/django/core/handlers/exception.py, строка 47, in inner response = get_response(request) ... ▶ Локальные переменные /home/timothy/.pyenv/versions/3.9.13/envs/mwp/lib/python3.9/site-packages/django/core/handlers/base.py, строка 204, in _get_response response = response.render()

Я включил это, чтобы помочь всем остальным, у кого может возникнуть такая же проблема.

Последняя мысль - почему это начало происходить около 3 месяцев назад? Gunicorn не обновлялся, наш конфиг не обновлялся/изменялся

Еще раз спасибо за мысли.

Вернуться на верх