Comment savoir pourquoi uWSGI tue des travailleurs?

J’ai l’application sur Pyramid. Je le lance dans uWSGI avec ces config:

[uwsgi] socket = mysite:8055 master = true processes = 4 vacuum = true lazy-apps = true gevent = 100 

Et nginx config:

 server { listen 8050; include uwsgi_params; location / { uwsgi_pass mysite:8055; } } 

Habituellement tout va bien, mais parfois, UWSGI tue les travailleurs. Et je ne sais pas pourquoi.

Je vois dans les journaux uWSGI:

• Comment passer l’adresse IP distante à un service mandaté? – Nginx
• Installer gevent dans virtualenv
• Comment résoudre cette erreur “NotImplementedError” urllib2 / gevent sur Windows?
• Utiliser gevent et multiprocessing ensemble pour communiquer avec un sous-processus
• Gevent WSGI ne gère pas les demandes simultanément

 DAMN ! worker 2 (pid: 4247) died, killed by signal 9 :( trying respawn ... Respawned uWSGI worker 2 (new pid: 4457) 

mais dans les journaux il n’y a pas d’exceptions Python.

parfois je vois dans les journaux uWSGI:

 invalid request block size: 11484 (max 4096)...skip [uwsgi-http key: my site:8050 client_addr: 127.0.0.1 client_port: 63367] hr_instance_read(): Connection reset by peer [plugins/http/http.c line 614] 

Et nginx errors.log:

 *13388 upstream prematurely closed connection while reading response header from upstream, client: 127.0.0.1, *13955 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 

Je pense que cela peut être résolu en ajoutant la taille du tampon = 32768, mais il est peu probable en raison de cette tuerie des uWSGI.

Pourquoi uwsgi peut tuer des travailleurs? Et comment puis-je connaître la raison? La ligne “DAMN! Worker 2 (pid: 4247) est morte, …” rien à dire.