web-dev-qa-db-fra.com

Erreur de temporisation du travailleur Gunicorn

J'ai installé gunicorn avec 3 travailleurs 30 connexions de travail et en utilisant la classe de travail Eventlet. Il est installé derrière Nginx. Après quelques demandes, je le vois dans les journaux.

[ERROR] gunicorn.error: WORKER TIMEOUT (pid:23475)
None
[INFO] gunicorn.error: Booting worker with pid: 23514

Pourquoi cela arrive-t-il? Comment puis-je savoir ce qui ne va pas?

merci

gunicorn
143
John

Nous avons eu le même problème avec Django + nginx + gunicorn. À partir de la documentation de Gunicorn, nous avons configuré le délai d’attente qui ne faisait presque aucune différence.

Après quelques tests, nous avons trouvé la solution, le paramètre à configurer est le suivant: timeout (et non pas le délai nécessaire). Cela fonctionne comme une horloge ..

Alors faites:

1) ouvrez le fichier de configuration gunicorn

2) réglez le TIMEOUT sur tout ce dont vous avez besoin - la valeur est exprimée en secondes

NUM_WORKERS=3
TIMEOUT=120

exec gunicorn ${Django_WSGI_MODULE}:application \
--name $NAME \
--workers $NUM_WORKERS \
--timeout $TIMEOUT \
--log-level=debug \
--bind=127.0.0.1:9000 \
--pid=$PIDFILE
122
Amit Talmor

Sur Google Cloud, ajoutez simplement --timeout 90 au point d'entrée dans app.yaml

entrypoint: gunicorn -b :$PORT main:app --timeout 90
21
Apoorv Agarwal

Exécutez Gunicorn avec --log-level=DEBUG.

Il devrait vous donner une trace de la pile de l'application.

18
gwik

Est-ce que ça pourrait être ça? http://docs.gunicorn.org/en/latest/settings.html#timeout

Il se peut aussi que votre réponse prenne trop de temps ou soit en attente.

9
Ranc

Vous devez utiliser une autre classe de type de travail, une classe asynchrone telle que gevent ou tornade, voyez ceci pour plus d'explications: Premier explantion:

Vous pouvez également installer Eventlet ou Gevent si vous vous attendez à ce que le code de votre application nécessite une pause prolongée pendant le traitement de la demande.

Deuxième :

Les travailleurs synchrones par défaut supposent que votre application est liée aux ressources en termes de processeur et de bande passante réseau. En règle générale, cela signifie que votre application ne doit rien faire qui prenne une durée indéterminée. Par exemple, une demande sur Internet répond à ce critère. À un moment donné, le réseau externe échouera de manière à ce que les clients s’empilent sur vos serveurs.

6
Dseed

J'ai eu un problème très similaire, j'ai également essayé d'utiliser "runserver" pour voir si je pouvais trouver quelque chose mais tout ce que j'avais était un message Killed

Alors j'ai pensé que cela pourrait être un problème de ressources, et j'ai décidé de donner plus de RAM à l'instance, et cela a fonctionné.

6
James Lin

WORKER TIMEOUT signifie que votre application ne peut pas répondre à la demande dans un délai défini. Vous pouvez définir ceci en utilisant paramètres de temporisation gunicorn . Certaines applications nécessitent plus de temps pour répondre que d’autres.

Une autre chose qui peut affecter ceci est choisir le type de travailleur

Les travailleurs synchrones par défaut supposent que votre application est liée aux ressources en termes de processeur et de bande passante réseau. En règle générale, cela signifie que votre application ne doit rien faire qui prenne une durée indéterminée. Une demande d’internet est un exemple de ce qui prend un laps de temps indéfini. À un moment donné, le réseau externe échouera de manière à ce que les clients s’empilent sur vos serveurs. Ainsi, dans ce sens, toute application Web qui effectue des requêtes sortantes vers des API bénéficiera d'un opérateur asynchrone.

Lorsque j'ai eu le même problème que le vôtre (j'essayais de déployer mon application à l'aide de Docker Swarm), j'ai essayé d'augmenter le délai d'attente et d'utiliser un autre type de classe de travailleurs. Mais tout a échoué.

Et puis je me suis soudain rendu compte que je limitais ma ressource trop basse pour le service contenu dans mon fichier de composition. C'est la chose qui a ralenti l'application dans mon cas

deploy:
  replicas: 5
  resources:
    limits:
      cpus: "0.1"
      memory: 50M
  restart_policy:
    condition: on-failure

Donc, je vous suggère de vérifier ce qui ralentit votre application en premier lieu

3
hashlash

Si vous utilisez GCP, vous devez définir des opérateurs par type d'instance.

Lien vers les meilleures pratiques GCP https://cloud.google.com/appengine/docs/standard/python3/runtime

1
Haider Lasne

J'ai le même problème chez Docker.

Dans Docker, je garde la formation LightGBM modèle + Flask demandes de service. En tant que serveur HTTP, j'ai utilisé gunicorn 19.9.0. Lorsque j'exécutais mon code localement sur mon ordinateur portable Mac, tout fonctionnait parfaitement, mais lorsque j'ai lancé l'application dans Docker, mes POST JSON demandes étaient gelées pendant un certain temps, puis un travailleur gunicorn avait échoué. [CRITICAL] WORKER TIMEOUT exception.

J'ai essayé des tonnes d'approches différentes, mais le seul qui ait résolu mon problème était d'ajouter worker_class=gthread.

Voici ma config complète:

import multiprocessing

workers = multiprocessing.cpu_count() * 2 + 1
accesslog = "-" # STDOUT
access_log_format = '%(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(q)s" "%(D)s"'
bind = "0.0.0.0:5000"
keepalive = 120
timeout = 120
worker_class = "gthread"
threads = 3
0
Artem Zaika