Gunicorn: Clarifier ce que/comment le délai d'attente et graceful_timeout fonctionnent

Hmm, je pense que https://github.com/benoitc/gunicorn/issues/1236#issuecomment -254059927 confirme mes hypothèses sur SIGTERM en mettant simplement le travailleur à l'arrêt une fois le traitement de la demande terminé (et en mettant le travailleur à ne pas accepter toute nouvelle connexion).

On dirait que la façon dont j'ai interprété timeout et graceful_timeout est fausse. Les deux périodes se réfèrent en fait au temps au début du traitement de la demande. Ainsi, par défaut, étant donné que les deux paramètres sont définis sur 30 secondes, aucun redémarrage progressif n'est activé. Si je fais quelque chose comme --graceful-timeout 15 --timeout 30 , cela devrait signifier que le redémarrage gracieux est lancé à 15 secondes et que le travailleur est tué de force à 30 secondes si la demande ne s'est pas terminée avant cela.

Cependant, il semble que si la réponse est renvoyée entre graceful_timeout et timeout , alors le travailleur n'est pas redémarré après tout ? Ne devrait-il pas?

J'ai testé par app.py :

import time
from flask import Flask

app = Flask(__name__)

@app.route('/foo')
def foo():
    time.sleep(3)
    return 'ok'

Puis:

12:51 $ gunicorn app:app --timeout 5 --graceful-timeout 1
[2017-04-03 12:51:37 +0300] [356] [INFO] Starting gunicorn 19.6.0
[2017-04-03 12:51:37 +0300] [356] [INFO] Listening at: http://127.0.0.1:8000 (356)
[2017-04-03 12:51:37 +0300] [356] [INFO] Using worker: sync
[2017-04-03 12:51:37 +0300] [359] [INFO] Booting worker with pid: 359

Ensuite, j'envoie curl localhost:8000/foo , qui revient après 3 secondes. Mais rien ne se passe dans le gunicorn - je ne vois aucune trace de redémarrage gracieux initié ou arrivé ?

Il semble que sur timeout , SystemExit(1,) soit lancé, annulant le traitement de la requête en cours dans Flask. Quel code ou signal le génère, je ne peux pas le dire.

Cette exception est lancée via la pile Flask et tous les gestionnaires teardown_request l'attrapent. Il y a suffisamment de temps pour enregistrer quelque chose, mais si vous faites time.sleep(1) ou quelque chose d'autre qui prend du temps dans le gestionnaire, il est tué en silence. C'est comme s'il y avait 100 à 200 ms avant que le processus ne soit effectivement terminé de force et je me demande quel est ce délai. Ce n'est pas un délai d'attente gracieux, ce paramètre n'a aucun impact sur le délai. Je m'attendrais à ce que le processus soit simplement tué de force sur place, au lieu de voir SystemExit être jeté à travers la pile, mais ensuite potentiellement tuer le processus en l'air de toute façon.

En fait, je ne vois pas graceful_timeout faire quoi que ce soit - peut-être qu'il n'est pas pris en charge pour les travailleurs de synchronisation, ou peut-être qu'il ne fonctionne pas "de manière autonome" (ou avec timeout ) - seulement lorsque vous envoyez manuellement SIGTERM ?

De plus, ce qui pourrait être étrange, c'est que https://github.com/benoitc/gunicorn/blob/master/gunicorn/arbiter.py#L392 ne vérifie pas du tout le drapeau graceful . Je suppose que https://github.com/benoitc/gunicorn/blob/master/gunicorn/arbiter.py#L390 garantit que self.WORKERS est vide afin que le délai d'attente gracieux ne soit pas attendu lors d'un arrêt non gracieux.

@benoitc @tilgovi Envie de donner un coup de main ici ? J'espère que mes écrits ci-dessus ont du sens...

@ tuco86 Le graceful timeout n'est disponible que lorsque vous quittez l'arbitre, le mettez à niveau (USR2), envoyez un signal HUP à l'arbitre ou envoyez un signal QUIT au travailleur. C'est-à-dire qu'il n'est utilisé que lorsque l'action est normale

Le délai d'attente est là pour empêcher les travailleurs occupés de bloquer les autres demandes. S'ils n'informent pas l'arbitre dans un délai inférieur à timeout , le travailleur est simplement quitté et la connexion avec le client est fermée.

Euh, d'accord. Est-ce que timeout a un effet lorsque vous :

quitter l'arbitre, le mettre à niveau (USR2), envoyer un signal HUP à l'arbitre ou envoyer un signal QUIT au travailleur

Je veux dire, que se passe-t-il si le travailleur ne s'arrête pas dans graceful_timeout ? timeout se déclenchera-t-il après cela et que les travailleurs seront tués de force, ou est-ce à l'utilisateur d'appeler SIGQUIT au cas où ils ne meurent pas gracieusement ?

Signal QUIT au travailleur

Je suppose que vous vouliez dire TERM ici (car QUIT est documenté comme _arrêt rapide_ pour le maître et les travailleurs) ?

si le travailleur ne s'arrête pas pendant le temps de grâce, il sera tué sans autre délai.

Bien sûr. Merci d'avoir clarifié les choses !

@benoitc Demander dans le contexte de cet ancien ticket - que signifie réellement la dernière phrase de la documentation timeout ?

Généralement réglé sur trente secondes. Ne réglez ce paramètre sensiblement plus haut que si vous êtes sûr des répercussions sur les travailleurs de la synchronisation. Pour les travailleurs non synchronisés, cela signifie simplement que le processus de travail communique toujours et n'est pas lié à la durée nécessaire pour traiter une seule demande.

N'étant pas de langue maternelle anglaise, j'ai du mal à comprendre cela. Cela signifie-t-il que timeout n'est pas pris en charge pour les travailleurs non synchronisés (parce que c'est ce dont je semble être témoin : j'utilise des travailleurs gthread et le délai d'expiration n'est pas activé et tue les demandes trop lentes ) ?

@tuukkamustonen --timeout n'est pas censé être un délai d'expiration de la demande. Il s'agit d'un test de vivacité pour les travailleurs. Pour les agents de synchronisation, cela fonctionne comme un délai d'attente de demande car l'agent ne peut rien faire d'autre que traiter la demande. Les travailleurs asynchrones battent même lorsqu'ils traitent des requêtes de longue durée, donc à moins que le travailleur ne le bloque/le bloque, il ne sera pas tué.

Ce serait peut-être une bonne idée pour nous de changer le nom si d'autres personnes trouvent cela déroutant.

@tilgovi timeout est très bien, même si quelque chose comme worker_timeout pourrait être plus descriptif. J'ai juste été d'abord confus parce que timeout et graceful_timeout sont déclarés l'un à côté de l'autre dans la documentation, donc mon cerveau a supposé qu'ils étaient étroitement connectés, alors qu'ils ne le sont pas.

Pour les agents de synchronisation, cela fonctionne comme un délai d'attente de demande car l'agent ne peut rien faire d'autre que traiter la demande. Les travailleurs asynchrones battent même lorsqu'ils traitent des requêtes de longue durée, donc à moins que le travailleur ne le bloque/le bloque, il ne sera pas tué.

Auriez-vous un exemple où timeout en jeu avec des travailleurs non synchronisés ? Est-ce quelque chose qui ne devrait jamais arriver, vraiment - peut-être seulement s'il y a un bogue qui provoque le blocage/gel du travailleur ?

C'est correct. Un travailleur asynchrone qui s'appuie sur un noyau de boucle d'événements peut exécuter une procédure gourmande en CPU qui ne produit pas dans le délai d'expiration.

Pas seulement un bug, en d'autres termes. Cependant, cela peut parfois indiquer un bogue, tel qu'un appel à une fonction d'E/S bloquante alors qu'un protocole asynchrone serait plus approprié.

Être bloqué dans une tâche intensive du processeur est un bon exemple, merci.

Appeler le blocage des E/S dans le code asynchrone en est un également, mais je ne sais pas comment cela s'applique à ce contexte - j'exécute une application Flask traditionnelle avec du code de blocage mais je l'exécute avec un travailleur asynchrone ( gthread ) sans aucune sorte de correctif de singe. Et ça marche bien. Je sais que ce n'est plus vraiment dans le contexte de ce ticket, mais le fait de mélanger et de faire correspondre le code asynchrone/synchronisé comme celui-ci ne pose-t-il pas de problèmes ?

De plus, quel est l'intervalle de battement de coeur ? Quelle serait une valeur sensée à utiliser pour timeout avec des travailleurs non synchronisés ?

Le travailleur gthread n'est pas asynchrone, mais il a un thread principal pour le battement de cœur afin qu'il n'expire pas non plus. Dans le cas de ce travailleur, vous ne verrez probablement pas de délai d'attente à moins que le travailleur ne soit très surchargé ou, plus probablement, que vous appeliez un module d'extension C qui ne libère pas le GIL.

Vous n'avez probablement pas besoin de modifier le délai d'expiration à moins que vous ne commenciez à voir des délais d'expiration de travailleur.

Bien. Encore une chose:

Le travailleur gthread n'est pas asynchrone

Il peut être un peu déroutant que le travailleur gthread ne soit pas asynchrone mais soit répertorié en tant que travailleurs "AsyncIO" sur http://docs.gunicorn.org/en/stable/design.html#asyncio -workers. En dehors de cela, l'utilisation de "threads" n'a pas besoin d'asyncio, ce qui soulève également des questions chez le lecteur. En disant cela du point de vue d'un utilisateur naïf, je suis sûr que tout cela est techniquement fondé.

En un mot, le travailleur gthread est implémenté avec asyncio lib mais il génère des threads pour gérer le code de synchronisation. Corrigez-moi si je me trompe.

Heureux que vous ayez demandé !

Le travailleur threadé n'utilise pas asyncio et n'hérite pas de la classe de travail asynchrone de base.

Nous devrions clarifier la documentation. Je pense qu'il a peut-être été répertorié comme asynchrone car le délai d'expiration du travailleur est géré simultanément, ce qui le fait se comporter davantage comme les travailleurs asynchrones que le travailleur de synchronisation en ce qui concerne la capacité à gérer les demandes longues et les demandes simultanées.

Ce serait formidable de clarifier la documentation et de la faire décrire plus précisément tous les travailleurs.

oui, le travailleur gthreads ne devrait pas être répertorié dans le travailleur asyncio. peut-être qu'avoir une section décrivant la conception de chaque travailleur est préférable ?

Rouvrir ceci afin que nous puissions le suivre comme un travail pour clarifier la section sur les types de travailleurs et les délais d'attente.

@tilgovi

--timeout n'est pas conçu comme un délai d'attente de requête. Il s'agit d'un test de vivacité pour les travailleurs. Pour les agents de synchronisation, cela fonctionne comme un délai d'attente de demande car l'agent ne peut rien faire d'autre que traiter la demande. Les travailleurs asynchrones battent même lorsqu'ils traitent des requêtes de longue durée, donc à moins que le travailleur ne le bloque/le bloque, il ne sera pas tué.

Existe-t-il une option de délai d'attente de demande disponible pour les travailleurs asynchrones ? En d'autres termes, comment faire en sorte qu'un arbitre tue un travailleur qui n'a pas traité une demande dans un délai spécifié ?

@aschatten il n'y en a pas, malheureusement. Voir aussi #1658.

tuer un travailleur qui n'a pas traité une demande dans un délai spécifié

Comme un travailleur peut traiter plusieurs demandes simultanément, tuer un travailleur entier parce qu'une demande expire semble assez extrême. Cela n'entraînerait-il pas que toutes les autres requêtes seraient tuées en vain ?

Je me souviens que uWSGI prévoyait d'introduire la mise à mort basée sur les threads dans la version 2.1 environ, bien que cela ne s'applique probablement qu'aux travailleurs synchronisés/threadés (et mes souvenirs à ce sujet sont vagues).

Comme un travailleur peut traiter plusieurs demandes simultanément, tuer un travailleur entier parce qu'une demande expire semble assez extrême. Cela n'entraînerait-il pas la mort de toutes les autres requêtes en vain ?

L'approche peut être la même que pour max_request , où il existe une implémentation distincte pour chaque type de travailleur.

Nous travaillons sur une version cette semaine, à quel point il est _peut-être_ temps de passer à R20, où nous prévoyons de nous attaquer à quelques problèmes majeurs. C'est peut-être le bon moment pour transformer le délai d'expiration actuel en un délai d'expiration de demande approprié pour chaque type de travailleur.

Commentant ici au lieu de déposer un problème séparé car j'essaie de comprendre comment le délai d'attente est censé fonctionner et je ne sais pas s'il s'agit d'un bogue ou non.

Le comportement inattendu de l'OMI que je vois est le suivant :

Chaque requête max-requests (celle après laquelle le travailleur sera redémarré) est dépassée, tandis que les autres requêtes sont terminées avec succès. Dans l'exemple ci-dessous, 4 requêtes sont exécutées, les requêtes 1, 2 et 4 réussissent, tandis que la requête 3 échoue.

Paramétrage concerné :

• travailleur gthread
• la demande de traitement prend plus de temps que le délai d'attente
• max-requests est différent de zéro

import time

def app(environ, start_response):
    start_response('200 OK', [('Content-type', 'text/plain; charset=utf-8')])
    time.sleep(5)
    return [b"Hello World\n"]

gunicorne :

gunicorn --log-level debug -k gthread -t 4 --max-requests 3 "app:app"
...
[2018-02-08 10:11:59 +0200] [28592] [INFO] Starting gunicorn 19.7.1
[2018-02-08 10:11:59 +0200] [28592] [DEBUG] Arbiter booted
[2018-02-08 10:11:59 +0200] [28592] [INFO] Listening at: http://127.0.0.1:8000 (28592)
[2018-02-08 10:11:59 +0200] [28592] [INFO] Using worker: gthread
[2018-02-08 10:11:59 +0200] [28595] [INFO] Booting worker with pid: 28595
[2018-02-08 10:11:59 +0200] [28592] [DEBUG] 1 workers
[2018-02-08 10:12:06 +0200] [28595] [DEBUG] GET /
[2018-02-08 10:12:11 +0200] [28595] [DEBUG] Closing connection.
[2018-02-08 10:12:15 +0200] [28595] [DEBUG] GET /
[2018-02-08 10:12:20 +0200] [28595] [DEBUG] Closing connection.
[2018-02-08 10:12:23 +0200] [28595] [DEBUG] GET /
[2018-02-08 10:12:23 +0200] [28595] [INFO] Autorestarting worker after current request.
[2018-02-08 10:12:27 +0200] [28592] [CRITICAL] WORKER TIMEOUT (pid:28595)
[2018-02-08 10:12:27 +0200] [28595] [INFO] Worker exiting (pid: 28595)
[2018-02-08 10:12:28 +0200] [28595] [DEBUG] Closing connection.
[2018-02-08 10:12:28 +0200] [28599] [INFO] Booting worker with pid: 28599
[2018-02-08 10:12:32 +0200] [28599] [DEBUG] GET /
[2018-02-08 10:12:37 +0200] [28599] [DEBUG] Closing connection.
^C[2018-02-08 10:12:39 +0200] [28592] [INFO] Handling signal: int

Client:

[salonen<strong i="19">@mac</strong> ~]$ curl http://127.0.0.1:8000
Hello World
[salonen<strong i="20">@mac</strong> ~]$ curl http://127.0.0.1:8000
Hello World
[salonen<strong i="21">@mac</strong> ~]$ curl http://127.0.0.1:8000
curl: (52) Empty reply from server
[salonen<strong i="22">@mac</strong> ~]$ curl http://127.0.0.1:8000
Hello World

quel devrait être le plan là-bas? J'ai en tête ce qui suit :

• [ ] mettre à jour la description du collaborateur (si nécessaire)
• [ ] documenter le protocole pour détecter les travailleurs morts ou bloqués

Devrait-il être 20,0 ou pourrions-nous le reporter?

report.

Hé, donc ça ne fera pas partie de la 20.0 ?

C'est peut-être le bon moment pour transformer le délai d'expiration actuel en un délai d'expiration de demande approprié pour chaque type de travailleur.

clarifié. @ lucas03 on ne sait pas quel est le délai d'expiration de la demande. veuillez ouvrir un ticket si vous avez besoin de quelque chose de spécifique ?.