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"

44

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;
}
Nigel Alderton
fuente
¿Qué fue cambiado ese día? ¿Actualizó su aplicación o PHP? ¿Cuál es tu aplicación? ¿Habilitó la depuración en php-fpm?
Pothi Kalimuthu
Nada fue cambiado ese día. La configuración del servidor no se modificó, ni tampoco los scripts PHP. No se queda sin espacio en disco. Mi aplicación es solo un conjunto de PHPscripts. No estoy usando php-fpm, solo estoy corriendo php-fastcgihaciendo php-cgi -b 127.0.0.1:9000. Ha estado funcionando sin fallas durante 3 años. No puedo entender por qué ha desarrollado este problema.
Nigel Alderton
Recientemente tuve un problema similar en el que nginx se quejaba del restablecimiento de la conexión por pares mientras leía el encabezado de respuesta desde arriba, en mi caso, era uWSGI el problema real, el reinicio de uWSGI me solucionó el problema, y ​​el por qué estaba sucediendo es un tema separado problema.
APZ
Su servicio ascendente ( php-cgi -b 127.0.0.1:9000) falla intermitentemente, tal vez debido al aumento del tráfico y la falta de recursos.
LinuxDevOps

Respuestas:

22

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
ese chico de allá
fuente
Okay. ¿Qué me dicen mis servidores web?
Nigel Alderton
ver mi edición (qué significa)
ese tipo de allá
2
Ya veo, así que Gatewayen este caso es el servidor PHP. Gracias.
Nigel Alderton
restart your fastcgi_process / serveres lo que me ayudó, thans
realtebo
11

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.
Gwyneth Llewelyn
fuente
+1 En mi caso fue el n. ° 1: error de programación.
Nimbuz
Nos encontramos con este error y deshabilitar la extensión PHP New Relic APM reveló un error más específico que nos permitió rastrear el problema: [29-ene-2018 16:47:48 UTC] Error fatal de PHP: tamaño de memoria permitido de 805306368 bytes agotado (intentó asignar 262144 bytes) en proveedor / magento / module-configurable-product / Pricing / Price / ConfigurableRegularPrice.php en la línea 142 [29-ene-2018 16:47:48 UTC] Error fatal de PHP: tamaño de memoria permitido de 805306368 bytes agotados (trató de asignar 323584 bytes) en Desconocido en la línea 0 Supongo que New Relic se atragantó en la ruta "Desconocida".
Erik Hansen el
7

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 
Manuel Riel
fuente
2

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

AMG anónimo
fuente
2

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

shgnInc
fuente
2

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

Vasiliy
fuente
lo mismo, en mi caso establecí una condición para un punto de interrupción y en ese momento desactivé el punto de ruptura, el error desapareció.
roman204
1

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.

Fabian Thommen
fuente
1

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.

Konstantin Pereiaslov
fuente
1

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

bruchowski
fuente
0

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!

Francisco
fuente