Um zu reproduzieren, starte gunicorn wie folgt:
gunicorn -w 1 --max-requests=0 --max-requests-jitter=10 -b 0.0.0.0:8000 api:app
Leiten Sie dann etwas Verkehr dorthin und beobachten Sie die folgende Protokollausgabe:
[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
Ich gehe davon aus, dass --max-requests-jitter
keine Auswirkung hat, wenn --max-requests
auf 0 gesetzt ist.
Welches Verhalten erwarten Sie? Normalerweise sollte max-requests=0
bedeuten, dass Arbeiter nie automatisch neu starten, aber aus Ihrem Protokoll sieht es so aus.
Dieser Fehler wurde in d4e1bfe5bd7801c160282310875c70cec15b7c07 eingeführt:
Die Zeile self.max_requests = cfg.max_requests + jitter or MAXSIZE
jetzt self.max_requests = cfg.max_requests + jitter or sys.maxsize
seit e974f30517261b2bc95cfb2017a8688f367c8bf3 setzt self.max_requests
auf den _jitter_-Wert.
Wir sollten self.max_requests
wirklich nur dann setzen, wenn der Einstellungswert größer als 0 ist.
@joekohlsdorf der obige Patch sollte den Fehler beheben, aber lass es uns wissen ...
Danke, sieht gut aus für mich.
Hilfreichster Kommentar
Dieser Fehler wurde in d4e1bfe5bd7801c160282310875c70cec15b7c07 eingeführt:
Die Zeile
self.max_requests = cfg.max_requests + jitter or MAXSIZE
jetztself.max_requests = cfg.max_requests + jitter or sys.maxsize
seit e974f30517261b2bc95cfb2017a8688f367c8bf3 setztself.max_requests
auf den _jitter_-Wert.Wir sollten
self.max_requests
wirklich nur dann setzen, wenn der Einstellungswert größer als 0 ist.