Errores de nginx "error de recv () (104: restablecimiento de la conexión por parte del mismo nivel) al leer el encabezado de respuesta desde el nivel superior"

Tengo un servidor que funcionaba bien hasta el 3 de octubre de 2013 a las 10:50 am cuando comenzó a devolver de forma intermitente los errores "502 Bad Gateway" al cliente.

Aproximadamente 4 de cada 5 solicitudes de navegador tienen éxito, pero aproximadamente 1 de cada 5 falla 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 coincidente.

¿Hay alguna manera de que PHP me brinde más información sobre por qué restablece 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 este es el .confpara 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;
}

Siempre confiaría si mis servidores web me dicen: 502 Bad Gateway

• ¿Cuál es el tiempo de actividad de su proceso fastcgi / nginx?
• ¿Monitorea las conexiones de red?
• ¿Puedes confirmar / negar un cambio en el recuento de visitantes alrededor de ese día?

Qué significa eso:

• nginx no puede acceder a su proceso fastcgi; ya sea para disminuir o no corresponde en absoluto. puerta de enlace incorrecta significa: nginx no puede fastcgi_pass a ese recurso definido 127.0.0.1:9000; en ese momento muy específico .

• 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 punto de vista limitado, sugeriría:

• reinicie su fastcgi_process / server
• revise su registro de acceso
• habilitar el registro de depuración

Sé que este tema es antiguo, pero todavía aparece de vez en cuando, así que, buscando respuestas en la web, encontré las siguientes tres posibilidades:

1. Un error de programación a veces es segfaulting php-fpm, lo que a su vez significa que la conexión con nginx se cortará. Esto generalmente dejará al menos algunos registros y / o volcados de núcleo, que pueden analizarse más a fondo.
2. Por alguna razón, PHP no puede escribir un archivo de sesión (generalmente:) session.save_path = "/var/lib/php/sessions". Esto puede ser malos permisos, mala propiedad, mal usuario / grupo o más problemas esotéricos / oscuros como quedarse sin inodos en ese directorio (¡o incluso un disco completo!). Esto generalmente no dejará muchos volcados de núcleo 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 comporta mal (ocasionalmente golpea algún tipo de límite interno, o un error que no se activa todo el tiempo), segfaulting, y trae el proceso php-fpm hacia abajo, cerrando así la conexión con nginx . Los culpables habituales son APC, memcache / d, etc. (en mi caso fue la extensión New Relic), por lo que la idea aquí es desactivar cada extensión hasta que desaparezca el error.

Seguí recibiendo esto también. Lo resolvió aumentando el opcachelímite de memoria, si lo usa (reemplazo de APC). Parece que PHP-FPM desconectó las conexiones cada vez que el caché se llenó demasiado. Esta es también la razón por la cual la respuesta de shgnInc lo soluciona por un corto tiempo.

Así que encuentre el archivo /etc/php5/fpm/php.ini(o equivalente en su distribución) y aumente memory_consumptional nivel que su sitio necesite. La desactivación opcachetambién puede funcionar.

[opcache]
opcache.memory_consumption = 196 

Es posible que desee considerar este git en github: https://gist.github.com/amichaelgrant/90d99d7d5d48bf8fd209

Encontré una situación similar, cuando revisé los registros de errores de mis servidores ascendentes, informaban algún error ulimit, así que lo aumenté a 1000000 (en los cuadros ascendentes y nginx) y todo funcionó bien

En mi caso del mismo problema, simplemente reinicio el php-fpmservicio para que se solucione.

sudo service php5-fpm restart

O algunas veces este problema ocurre debido a la gran cantidad de solicitudes. Por defecto, pm.max_requestsen php5-fpm quizás sea 100 o inferior.

Para resolverlo, aumentar su valor depende de las solicitudes de su sitio, por ejemplo 500.

Y después de que tengas que reiniciar el servicio

En mi caso, deshabilitar la extensión xdebug ayudó.

Acabo de tener un problema similar:

Se conecta a php-fpm en el puerto 9000. (fastcgi: //127.0.0.1: 9000)

La configuración estándar en Ubuntu en mi servidor es:

/etc/php/7.0/fpm/pool.d/www.conf:

listen = /run/php/php7.0-fpm.sock

tienes que cambiar esto a:

listen = 0.0.0.0:9000

En mi caso, actualicé mi servidor hace 1 1/2 mes, sobrescribiendo mi configuración de costom con el valor predeterminado. Ahora, después de reiniciar php-fpm, este error entró en vigencia con retraso.

Para mí, el servidor se estaba quedando sin memoria y php-fpm fue asesinado por OOM killer. La solución fue aumentar la cantidad de memoria del servidor.

Para mí fue porque php-fpm estaba llegando al max_childrenlímite. El registro php-fpm para el grupo en cuestión me señaló en la dirección correcta

Este problema también puede surgir si un proceso PHP-FPM excede su límite de memoria asignado. Cuando esto sucede, la conexión entre NGINX y PHP-FPM se corta y NGINX devuelve a 502 Bad Gateway. El límite de memoria del proceso PHP-FPM está controlado por la memory_limitvariable. Esto se puede configurar php_admin_value[memory_limit]en el archivo de configuración PHP-FPM.

Es importante tener en cuenta que el límite de memoria se aplica por script . Con nlos procesos PHP-FPM, el uso total de memoria puede ser de hastamemory_limit * n . ¡Asegúrese de verificar que su máquina tenga suficiente espacio libre de memoria!