Pour reproduire, lancez gunicorn comme ceci :
gunicorn -w 1 --max-requests=0 --max-requests-jitter=10 -b 0.0.0.0:8000 api:app
Dirigez ensuite une partie du trafic vers celui-ci et observez la sortie de journal suivante :
[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
Je m'attends à ce que --max-requests-jitter
n'ait aucun effet lorsque --max-requests
est défini sur 0.
Quel est le comportement que vous attendez ? Normalement, max-requests=0
devrait signifier que les travailleurs ne redémarrent jamais automatiquement, mais d'après votre journal, cela semble être le cas.
Cette erreur a été introduite dans d4e1bfe5bd7801c160282310875c70cec15b7c07 :
La ligne self.max_requests = cfg.max_requests + jitter or MAXSIZE
now self.max_requests = cfg.max_requests + jitter or sys.maxsize
depuis e974f30517261b2bc95cfb2017a8688f367c8bf3 définira self.max_requests
sur la valeur _jitter_.
Nous ne devrions vraiment définir self.max_requests
que si sa valeur de réglage est supérieure à 0.
@joekohlsdorf le correctif ci-dessus devrait corriger l'erreur mais faites-le nous savoir...
Merci, ça m'a l'air bien.
Commentaire le plus utile
Cette erreur a été introduite dans d4e1bfe5bd7801c160282310875c70cec15b7c07 :
La ligne
self.max_requests = cfg.max_requests + jitter or MAXSIZE
nowself.max_requests = cfg.max_requests + jitter or sys.maxsize
depuis e974f30517261b2bc95cfb2017a8688f367c8bf3 définiraself.max_requests
sur la valeur _jitter_.Nous ne devrions vraiment définir
self.max_requests
que si sa valeur de réglage est supérieure à 0.