rails - NGINX: tiempo de espera en sentido ascendente(110: tiempo de espera de conexión agotado) mientras se lee el encabezado de respuesta de la corriente ascendente

nginx rails

Question

Tengo Puma corriendo como el servidor de aplicaciones aguas arriba y Riak como mi clúster db de fondo. Cuando envío una solicitud de que el mapa reduce un fragmento de datos para unos 25 000 usuarios y lo devuelve desde Riak a la aplicación, aparece un error en el registro de Nginx:

tiempo de espera en sentido ascendente (110: tiempo de espera de conexión agotado) mientras se lee el encabezado de respuesta de la corriente ascendente

Si consulto mi upstream directamente sin el proxy nginx, con la misma solicitud, obtengo los datos requeridos.

El tiempo de espera de Nginx ocurre una vez que se coloca el proxy.

**nginx.conf**
http {
keepalive_timeout 10m;
proxy_connect_timeout 600s;
proxy_send_timeout 600s;
proxy_read_timeout 600s;
fastcgi_send_timeout 600s;
fastcgi_read_timeout 600s;
include /etc/nginx/sites-enabled/*.conf;
}
**virtual host conf**
upstream ss_api {
server 127.0.0.1:3000 max_fails=0 fail_timeout=600;
}
server {
listen 81;
server_name xxxxx.com; # change to match your URL
location / {
# match the name of upstream directive which is defined above
proxy_pass http://ss_api;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_cache cloud;
proxy_cache_valid 200 302 60m;
proxy_cache_valid 404 1m;
proxy_cache_bypass $http_authorization;
proxy_cache_bypass http://ss_api/account/;
add_header X-Cache-Status $upstream_cache_status;
}
}

Nginx tiene un montón de directivas de tiempo de espera. No sé si me estoy perdiendo algo importante. Cualquier ayuda sería muy apreciada....

Answer 1

Creo que este error puede ocurrir por varias razones, pero puede ser específico del módulo que está utilizando. Por ejemplo, vi esto usando el módulo uwsgi, así que tuve que configurar "uwsgi_read_timeout".

Answer 2

En su caso, ayuda a una pequeña optimización en el proxy, o puede usar "# time out settings"

location /
{
# time out settings
proxy_connect_timeout 159s;
proxy_send_timeout 600;
proxy_read_timeout 600;
proxy_buffer_size 64k;
proxy_buffers 16 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
proxy_pass_header Set-Cookie;
proxy_redirect off;
proxy_hide_header Vary;
proxy_set_header Accept-Encoding '''';
proxy_ignore_headers Cache-Control Expires;
proxy_set_header Referer $http_referer;
proxy_set_header Host $host;
proxy_set_header Cookie $http_cookie;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

Answer 3

Esto sucede porque su upstream toma demasiado para responder a la solicitud y NGINX piensa que el upstream ya falló en el procesamiento de la solicitud, por lo que responde con un error. Simplemente incluya y aumente proxy_read_timeout en la ubicación. Lo mismo me sucedió a mí y utilicé un tiempo de espera de 1 hora para una aplicación interna en el trabajo:

proxy_read_timeout 3600;

Con esto, NGINX esperará una hora para que su flujo ascendente devuelva algo.

Answer 4

Por nuestra parte, estaba usando spdy con proxy caché. Cuando la memoria caché caduca, obtenemos este error hasta que la memoria caché se haya actualizado.

Answer 5

Primero averigüe qué flujo ascendente se está desacelerando al consultar el archivo de registro de errores de nginx y ajustar el tiempo de salida de lectura en consecuencia en mi caso fue fastCGI

2017/09/27 13:34:03 [error] 16559#16559: *14381 upstream timed out (110: Connection timed out) while reading response header from upstream, client:xxxxxxxxxxxxxxxxxxxxxxxxx", upstream: "fastcgi://unix:/var/run/php/php5.6-fpm.sock", host: "xxxxxxxxxxxxxxx", referrer: "xxxxxxxxxxxxxxxxxxxx"

Así que tengo que ajustar el fastcgi_read_timeout en la configuración de mi servidor

.........................
location ~ /.php$ {
fastcgi_read_timeout 240;
............
}
................................

Ver: publicación original

Answer 6

Siempre debe abstenerse de aumentar los tiempos de espera, dudo que el tiempo de respuesta del servidor de back-end sea el problema aquí en cualquier caso.

Solucioné este problema borrando la bandera keep-alive de conexión y especificando la versión http según la respuesta aquí: https://.com/a/36589120/479632

server {
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $http_host;
# these two lines here
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_pass http://localhost:5000;
}
}

Lamentablemente, no puedo explicar por qué funciona esto y no logré descifrarlo de los documentos mencionados en la respuesta vinculada, así que si alguien tiene una explicación, estaría muy interesado en escucharla.

Answer 7

Tuve el mismo problema y resultó que era un error "todos los días" en el controlador de rieles. No sé por qué, pero en producción, puma ejecuta el error una y otra vez provocando el mensaje:

tiempo de espera en sentido ascendente (110: tiempo de espera de conexión agotado) mientras se lee el encabezado de respuesta de la corriente ascendente

Probablemente porque Nginx intenta obtener los datos del puma una y otra vez. Lo curioso es que el error provocó el mensaje de tiempo de espera incluso si estoy llamando a una acción diferente en el controlador, por lo que un solo error bloquea toda la aplicación.

Verifique su archivo log / puma.stderr.log para ver si esa es la situación.

Answer 8

Yo recomendaría mirar los errores_logs, específicamente en la parte de arriba donde se muestra el upstream específico que está expirando.

Luego, en función de eso, puede ajustar proxy_read_timeout fastcgi_read_timeout o uwsgi_read_timeout.

También asegúrese de que su configuración esté cargada.

Más detalles aquí Nginx upstream timed out (por qué y cómo solucionarlo)