2011-07-25 69 views
47

Estoy ejecutando django en gunicorn + nginx. Estoy enfrentando un problema con la carga de archivos. En realidad subidas están trabajando bien, pero los tiempos gunicorn a cabo por lo tanto causando esto en nginx:Gunicorn Nginx problema de tiempo de espera

2011/07/25 12:13:47 [error] 15169#0: *2317 upstream timed out (110: Connection timed out) while reading response header from upstream, client: IP-ADDRESS, server: SERVER, request: "GET /photos/events/event/25 HTTP/1.1", upstream: "http://127.0.0.1:29000/photos/events/event/25", host: "HOST", referrer: "REFERER_ADDRESS" 

Si actualiza la página, puedo ver todas las fotos se cargan muy bien. El problema es que provoca un tiempo de espera, lo que da la impresión de que la carga no funcionó.

aquí es mi gunicorn conf:

bind = "127.0.0.1:29000" 
logfile = "/path/to/logs/gunicorn.log" 
workers = 3 

He intentado cambiar el tiempo de espera, pero no funcionó.

+0

¿Cuánto tardan en cargarse estos archivos antes de recibir el error? –

+0

en cualquier lugar entre unos segundos a un minuto, dependiendo del tamaño del archivo y la velocidad de mi conexión. (mi velocidad varía mucho :)). Incluso obtengo estos para archivos de 20 kb a veces. –

+0

¿Hay algún tipo de zócalo o primitiva de comunicación que te olvides de cerrar? – sholsapp

Respuesta

65

Usted podría intentar actualizar el tiempo de espera para su pase proxy en Nginx añadiendo:

proxy_connect_timeout 75s; 
proxy_read_timeout 300s; 

en/var/nginx/sites-available/[site-config] o /var/nginx/nginx.conf si desea aumentar el límite de tiempo de espera en todos los sitios servidos por nginx.

Debe agregar --timeout 300 también a su proceso/configuración de gunicornio.

Esto resolvió mis problemas en el pasado con cargas mayores.

+4

proxy_connect_timeout <= 75s. http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_connect_timeout – zubinmehta

+1

lo haría más uno esto varias veces. Esta es la razón por la que tuve el dolor de cabeza de todos los archivos subidos y pasé horas revisando mi código y rompiendo mi settings.py varias veces. Me estoy mudando a uwsgi en su lugar. – Vangel

+2

Para el registro, estaba teniendo algunos problemas de tiempo de archivo/procesamiento de gran tamaño, y el ajuste del valor de "tiempo de espera" en la configuración de gunicornio es exactamente lo que necesitaba para resolverlo. Gracias por mencionar eso! –

24

Esto no es un tiempo de espera nginx, pero probablemente un tiempo de espera de Gunicorn. Gunicorn está predeterminado a un tiempo de espera de 30 segundos.

En general, debe solucionar esto al no tener un punto final que demore más de 30 segundos en regresar, pero si se trata de un punto final que rara vez se usa, también puede aumentar el tiempo de espera de gunicornio. Si haces esto, probablemente también deberías aumentar el número de procesos de los trabajadores de gunicornio.

Para aumentar el tiempo de espera y los trabajadores para gunicorn, puede agregar las siguientes opciones de línea de comandos en el arranque:

gunicorn --timeout 120 --workers

+4

Verdadero, pero 'proxy_read_timeout' en nginx tiene un valor predeterminado de 60, por lo que si su proceso en gUnicorn necesita más que eso para responder, también necesita aumentarlo. http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout – laurent

+0

Genial ... ¡Esta fue una trampa difícil! ¡lo tengo! ¡Muchas gracias! – Sharath

11

Tuvimos el mismo problema usando Django + Nginx + gunicornio De la documentación de Gunicorn hemos configurado el tiempo de gracia que casi no hizo diferencia.

Después de algunas pruebas, encontramos la solución, el parámetro para configurar es: tiempo de espera (y no tiempo de gracia). Funciona como un reloj ..

Así, Do:

1) abrir el fichero de configuración gunicorn

2) establecer el tiempo a lo que usted necesita - el valor está en segundo

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 
+0

Esto me solucionó el problema. ¡Gracias! –

0

Esto podría ayudar a alguien con un problema similar.

Estaba obteniendo el error de tiempo de espera de nginx y gunicorn en mi aplicación Django. Como obtenía el error de tiempo de espera de nginx, no pude ver el error real de Django. Después de agregar el nuevo tiempo de espera como fijter sugirió. Pude ver que el error estaba en el archivo settings.py.

Si establece DEPURAR en Falso y no agrega el nombre de dominio en ALLOWED_HOSTS, puede obtener este error.

Acabo de agregar el dominio en ALLOWED_HOSTS en settings.py y el error desapareció.

¡Solución muy simple!

+3

no relacionado con la pregunta, ALLOWED_HOSTS mal configurado no causa 502 –

+0

Estaba recibiendo 'conexión cerrada' debido a no agregar' nombre de dominio' en 'ALLOWED_HOSTS' –

Cuestiones relacionadas