Чтобы воспроизвести, запустите Gunicorn следующим образом:
gunicorn -w 1 --max-requests=0 --max-requests-jitter=10 -b 0.0.0.0:8000 api:app
Затем направьте на него некоторый трафик и посмотрите следующий вывод журнала:
[2019-02-05 20:27:23 +0000] [19] [INFO] Starting gunicorn 19.9.0
[2019-02-05 20:27:23 +0000] [19] [INFO] Listening at: http://0.0.0.0:8000 (19)
[2019-02-05 20:27:23 +0000] [19] [INFO] Using worker: sync
[2019-02-05 20:27:23 +0000] [22] [INFO] Booting worker with pid: 22
[2019-02-05 20:27:37 +0000] [22] [INFO] Autorestarting worker after current request.
[2019-02-05 20:27:37 +0000] [22] [INFO] Worker exiting (pid: 22)
[2019-02-05 20:27:37 +0000] [24] [INFO] Booting worker with pid: 24
Я ожидаю, что --max-requests-jitter
не действует, если --max-requests
установлено в 0.
Какого поведения вы ожидаете? Обычно max-requests=0
должно означать, что рабочие никогда не перезапускаются автоматически, но из вашего журнала это выглядит так, как будто это происходит.
Эта ошибка была введена в d4e1bfe5bd7801c160282310875c70cec15b7c07:
Строка self.max_requests = cfg.max_requests + jitter or MAXSIZE
now self.max_requests = cfg.max_requests + jitter or sys.maxsize
с момента e974f30517261b2bc95cfb2017a8688f367c8bf3 установит self.max_requests
в значение _jitter_.
Нам действительно следует устанавливать self.max_requests
только если его значение настройки больше 0.
@joekohlsdorf патч выше должен исправить ошибку, но дайте нам знать ...
Спасибо, все в порядке.
Самый полезный комментарий
Эта ошибка была введена в d4e1bfe5bd7801c160282310875c70cec15b7c07:
Строка
self.max_requests = cfg.max_requests + jitter or MAXSIZE
nowself.max_requests = cfg.max_requests + jitter or sys.maxsize
с момента e974f30517261b2bc95cfb2017a8688f367c8bf3 установитself.max_requests
в значение _jitter_.Нам действительно следует устанавливать
self.max_requests
только если его значение настройки больше 0.