Возрождается работник uWSGI, хотя запрос еще не завершен - PullRequest
Новая
       21

Возрождается работник uWSGI, хотя запрос еще не завершен

0 голосов
/ 06 ноября 2019

Я написал приложение фляги на основе этого учебника

Мое приложение ведет себя как своего рода распространитель файлов. Он принимает файлы и распространяет их по разным API в других системах.

Иногда я вижу следующую ошибку в журнале ошибок nginx. 

2019/11/06 14:01:01 [error] 28912#28912: *19810346 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.2.60, server: my.host.local, request: "POST /file/add HTTP/1.1", upstream: "uwsgi://unix:/var/my_project/myproject.sock:", host: "my.host.local"

Я включил ведение журнала uWSGI и заметил, что, когда uWSGI повторно вызывает своих работников через 60 секунд, также появляется ошибка в журнале nginx. Это не происходит постоянно, но в большинстве случаев (~ 90%) это так. Иногда это просто работает, так что я думаю, это должно быть время или что-то в этом роде.

Если я не ошибаюсь в своих предположениях, увеличение продолжительности жизни работника должно уменьшить количество событий ошибок в журнале nginx. На самом деле, uWSGI не должен просто возродить работника, пока запрос не завершен, так в чем же проблема?

INI-файл uWSGI: 

[uwsgi]
module = wsgi:app

master = true
processes = 48
threads = 2
enable-threads = True

limit-as = 512

disable-logging = True
buffer-size = 65535
max-worker-lifetime = 60

socket = myproject.sock
chmod-socket = 660
vacuum = true

die-on-term = true

#location of log files
logto = /var/log/uwsgi/%n.log

Мое приложение работает на Ubuntu 18.04.3 Виртуальная машина LTS с 24 процессорами и 128 ГБ ОЗУ (я знаю, что это может быть излишним, но это только для тестирования.)

1 Ответ

0 голосов
/ 06 ноября 2019

Когда uwsgi вызывает своих работников, кажется, что срабатывает тайм-аут harakiri. Режим

harakiri заставляет uwsgi перезапускать рабочий процесс, если соответствующий ответ требует большечем harakiri_seconds , вы можете увеличить время ожидания, например: 

harakiri = 120  # 2 mins

Но вы действительно должны проверить, какая конечная точка так долго отвечает, 60 секунд, чтобы веб-служба отправилаответа уже слишком много.

Также обратите внимание, что Nginx ngx_http_uwsgi_module также имеет разные параметры времени ожидания для разных частей цикла запрос-ответ, но из сообщения об ошибке ошибкаказалось, было связано с верхним течением (uwsgi). Но для вашего собственного понимания вы также можете посмотреть соответствующие директивы.

...