58 votos

104: Restablecimiento de la conexión por parte del compañero mientras lee la cabecera de la respuesta desde el flujo ascendente (Nginx)

Tengo un servidor que funcionaba bien hasta el 3 de octubre de 2013 a las 10:50h cuando empezó a devolver intermitentemente errores "502 Bad Gateway" al cliente.

Aproximadamente 4 de cada 5 solicitudes del navegador tienen éxito, pero alrededor de 1 de cada 5 fallan con un 502.

El registro de errores de nginx contiene muchos cientos de estos errores;

2013/10/05 06:28:17 [error] 3111#0: *54528 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 66.249.66.75, server: www.bec-components.co.uk  request: ""GET /?_n=Fridgefreezer/Hotpoint/8591P;_i=x8078 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.bec-components.co.uk"

Sin embargo, el registro de errores de PHP no contiene ningún error que coincida.

¿Hay alguna manera de hacer que PHP me dé más información sobre por qué está restableciendo la conexión?

Esto es nginx.conf ;

user              www-data;
worker_processes  4;
error_log         /var/log/nginx/error.log;
pid               /var/run/nginx.pid;

events {
   worker_connections  1024;
}

http {
  include          /etc/nginx/mime.types;
  access_log       /var/log/nginx/access.log;

  sendfile               on;
  keepalive_timeout      30;
  tcp_nodelay            on;
  client_max_body_size   100m;

  gzip         on;
  gzip_types   text/plain application/xml text/javascript application/x-javascript text/css;
  gzip_disable "MSIE [1-6]\.(?!.*SV1)";

  include /gvol/sites/*/nginx.conf;

}

Y esta es la .conf para este sitio;

server {

  server_name   www.bec-components.co.uk bec3.uk.to bec4.uk.to bec.home;
  root          /gvol/sites/bec/www/;
  index         index.php index.html;

  location ~ \.(js|css|png|jpg|jpeg|gif|ico)$ {
    expires        2592000;   # 30 days
    log_not_found  off;
  }

  ## Trigger client to download instead of display '.xml' files.
  location ~ \.xml$ {
    add_header Content-disposition "attachment; filename=$1";
  }

   location ~ \.php$ {
      fastcgi_read_timeout  3600;
      include               /etc/nginx/fastcgi_params;
      keepalive_timeout     0;
      fastcgi_param         SCRIPT_FILENAME  $document_root$fastcgi_script_name;
      fastcgi_pass          127.0.0.1:9000;
      fastcgi_index         index.php;
   }
}

## bec-components.co.uk ##
server {
   server_name   bec-components.co.uk;
   rewrite       ^/(.*) http://www.bec-components.co.uk$1 permanent;
}

0 votos

¿Qué se cambió ese día? ¿Actualizó su aplicación o PHP? ¿Cuál es su aplicación? ¿Habilitaste la depuración en php-fpm?

0 votos

Ese día no se cambió nada. La configuración del servidor no fue cambiada, ni tampoco ningún scripts. No se ha quedado sin espacio en disco. Mi aplicación es sólo un conjunto de PHP scripts. No estoy usando php-fpm Sólo estoy corriendo php-fastcgi haciendo php-cgi -b 127.0.0.1:9000 . Lleva 3 años funcionando sin fallos. No puedo entender por qué ha desarrollado este problema.

0 votos

Recientemente tuve un problema similar en el que nginx se quejaba de Connection reset by peer mientras leía la cabecera de respuesta de upstream, en mi caso era uWSGI el verdadero problema, reiniciando uWSGI se solucionó el problema para mí, en cuanto a por qué estaba sucediendo es un tema aparte.

29voto

Siempre me fío de lo que me dicen mis servidores web: 502 Bad Gateway

  • ¿cuál es el tiempo de actividad de su proceso fastcgi/nginx?
  • ¿controla las conexiones de red?
  • ¿puede confirmar/desconocer un cambio en el recuento de visitantes en torno a ese día?

qué significa:

  • tu proceso fastcgi no es accesible por nginx; o bien es muy lento o no corresponde en absoluto. bad gateway significa: nginx no puede fastcgi_pass a ese recurso definido 127.0.0.1:9000; en ese momento concreto .

  • sus registros de errores iniciales lo dicen todo:

.

recv() failed 
    -> nginx failed

(104: Connection reset by peer) while reading response header from upstream, 
    -> no complete answer, or no answer at all
upstream: "fastcgi://127.0.0.1:9000", 
    -> who is he, who failed???

desde mi limitado punto de vista sugeriría:

  • reinicie su fastcgi_process / servidor
  • compruebe su registro de acceso
  • activar debug-log

0 votos

Bien. ¿Qué me dicen mis servidores web?

0 votos

ver mi edición (qué significa)

2 votos

Ya veo, así que el Gateway en este caso es el servidor PHP. Gracias.

17voto

Gwyneth Llewelyn Puntos 251

Sé que este tema es antiguo, pero sigue apareciendo de vez en cuando, así que, buscando respuestas en la web, se me ocurrieron las siguientes tres posibilidades:

  1. Un error de programación es a veces segfaulting php-fpm, que a su vez significa que la conexión con nginx se cortará. Esto suele dejar al menos algunos registros alrededor y/o volcados del núcleo, que pueden ser analizados más a fondo.
  2. Por alguna razón, PHP no está siendo capaz de escribir un archivo de sesión (normalmente: session.save_path = "/var/lib/php/sessions" ). Puede tratarse de permisos erróneos, propiedad errónea, usuario/grupo erróneo, o problemas más esotéricos/obscuros como quedarse sin inodos en ese directorio (¡o incluso un disco lleno!). Por lo general, esto no dejar muchos volcados del núcleo por ahí y posiblemente ni siquiera nada en los registros de errores de PHP.
  3. Aún más difícil de depurar: una extensión se está comportando mal (ocasionalmente golpeando algún tipo de límite interno, o un error que no se activa todo el tiempo), segfaulting, y trayendo el proceso php-fpm abajo con él - cerrando así la conexión con nginx. Los culpables habituales son APC, memcache/d, etc. (en mi caso fue la extensión de New Relic), así que la idea aquí es desactivar cada extensión hasta que el error desaparezca.

1 votos

+1 En mi caso fue el número 1, un error de programación.

1 votos

Nos encontramos con este error y al desactivar la extensión PHP de New Relic APM se reveló un error más específico que nos permitió localizar el problema: [29-Ene-2018 16:47:48 UTC] PHP Fatal error: Allowed memory size of 805306368 bytes exhausted (tried to allocate 262144 bytes) in vendor/magento/module-configurable-product/Pricing/Price/ConfigurableRegularPrice.php on line 142 [29-Ene-2018 16:47:48 UTC] PHP Fatal error: Allowed memory size of 805306368 bytes exhausted (tried to allocate 323584 bytes) in Unknown on line 0 Mi conjetura es que New Relic se ahogó en la ruta "Unknown".

0 votos

Ty en mi caso el código era segfaulting de alguna manera, la eliminación de línea por línea me dio esta confirmación.

8voto

Mewtei Puntos 1

A mí también me pasaba esto. Lo resolví aumentando el opcache Límite de memoria, si se utiliza (reemplazo de APC). Parece que PHP-FPM deja caer las conexiones cuando el caché se llena demasiado. Esta es también la razón por la que la respuesta de shgnInc lo arregla por un corto tiempo.

Así que busca el archivo /etc/php5/fpm/php.ini (o su equivalente en su distribución) y aumentar memory_consumption a cualquier nivel que su sitio necesite. Desactivación de opcache también puede funcionar.

[opcache]
opcache.memory_consumption = 196

0 votos

Cómo se desactiva opcache ?

6voto

shgnInc Puntos 334

En mi caso del mismo problema, simplemente reinicio el php-fpm servicio por lo que resolvió.

sudo service php5-fpm restart

O algunas veces este problema ocurre debido a la gran cantidad de solicitudes. Por defecto el pm.max_requests en php5-fpm tal vez sea 100 o menos.

Para solucionarlo aumenta su valor en función de las peticiones de su sitio, Por ejemplo 500.

Y después hay que reiniciar el servicio

2voto

AMG Anonymous Puntos 1

Quizás quieras considerar este git en github: https://gist.github.com/amichaelgrant/90d99d7d5d48bf8fd209

Me encontré con una situación similar, cuando revisé los registros de error de mis servidores upstream estaban reportando algún error ulimit así que aumenté eso a 1000000(en ambas cajas upstream y nginx) y todo funcionó bien

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: