web-dev-qa-db-fra.com

uWSGI déclenche OSError: erreur d'écriture lors d'une requête volumineuse

Mon application utilise nginx, avec uWSGI côté serveur. Lorsque je fais une demande importante (avec un temps de réponse> 4 s), ce qui suit apparaît:

SIGPIPE: writing to a closed pipe/socket/fd (probably the client
    disconnected) on request _URL_ (ip XX.XX.XX.XX) !!!

uwsgi_response_writev_headers_and_body_do(): Broken pipe
    [core/writer.c line 287] during GET _URL_ (XX.XX.XX.XX)

OSError: write error

Il semble que uWSGI essaie d'écrire dans un flux mais ce flux a déjà été fermé. Lorsque je vérifie le journal nginx (error.log):

upstream prematurely closed connection while reading response
    header from upstream ...

Bien sûr, mon client (client REST ou navigateur) reçoit une erreur 502.

J'obtiens toujours cette erreur après ~ 4s.

Cependant, je ne sais pas comment éviter ce problème. J'ai essayé de définir certains paramètres dans mon fichier de configuration nginx:

location my_api_url {
    [...]
    uwsgi_buffer_size 32k;
    uwsgi_buffers 8 32k;
    uwsgi_busy_buffers_size 32k;

    uwsgi_read_timeout 300;
    uwsgi_send_timeout 300;

    uwsgi_connect_timeout 60;
}

Mais le problème est toujours là. J'ai également essayé de définir ces paramètres dans le fichier de configuration uWSGI (wsgi.ini):

buffer-size=8192
ignore-sigpipe=true
ignore-write-errors=true

Avant d'essayer d'optimiser le temps de réponse, j'espère que ce problème a une solution. Je n'en trouve pas qui fonctionne dans un autre poste. Je travaille avec une grande quantité de données, donc mon temps de réponse, dans certains cas, sera compris entre 4 et 10 secondes.

J'espère que vous pourrez m'aider :)

Merci beaucoup d'avance.

pythonnginxuwsgi
22
JulCh

Il se peut que lorsque vous téléchargez des éléments, vous utilisez un codage en morceaux. Il y a l'option uWSGI --chunked-input-timeout , qui par défaut est de 4 secondes (it par défaut à la valeur de --socket-timeout, ce qui correspond à 4 secondes).

Bien que le problème puisse théoriquement se situer ailleurs, je vous suggère d'essayer les options susmentionnées. De plus, des exceptions ennuyeuses sont la raison pour laquelle j'ai

ignore-sigpipe=true
ignore-write-errors=true
disable-write-exception=true

dans ma configuration uWSGI (notez que je propose 3 options, pas 2):

  • ignore-sigpipe fait que uWSGI n'affiche pas les erreurs SIGPIPE;
  • ignore-write-errors ne fait pas apparaître d'erreurs avec par exemple uwsgi_response_writev_headers_and_body_do;
  • disable-write-exception empêche OSError la génération lors des écritures.
19
paka

Dans mon cas, Nginx en tant que backproxy d'uwsgi, la config http-timeout définit le serveur pour qu'il attende normalement dans les requêtes de longue durée.

N'oubliez pas que les options suivantes sont incluses dans la déclaration de proxy nginx:

proxy_read_timeout 300s;
proxy_connect_timeout 300s;
proxy_send_timeout 300s;

ne faisaient rien concernant le délai d'expiration de la passerelle.

0
Evhz