Erros nginx “recv () falhou (104: Conexão redefinida pelo par) ao ler o cabeçalho de resposta do upstream”

Eu tenho um servidor que estava funcionando bem até 3 de outubro de 2013 às 10:50, quando começou a retornar intermitentemente erros "502 Bad Gateway" para o cliente.

Aproximadamente 4 em cada 5 solicitações de navegador são bem-sucedidas, mas cerca de 1 em 5 falha com um 502.

O log de erros do nginx contém muitas centenas desses erros;

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"

No entanto, o log de erros do PHP não contém nenhum erro correspondente.

Existe uma maneira de obter o PHP para me dar mais informações sobre por que ele está redefinindo a conexão?

Isto é 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;

}

E este é o .confsite deste site;

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;
}

eu sempre confiaria se meus servidores da web estivessem me dizendo: 502 Bad Gateway

• qual é o tempo de atividade do seu processo fastcgi / nginx?
• você monitora conexões de rede?
• você pode confirmar / negar uma alteração na contagem de visitantes naquele dia?

O que isso significa:

• seu processo fastcgi não é acessível pelo nginx; desacelerar ou não corresponder. gateway incorreto significa: o nginx não pode fastcgi_pass para o recurso definido 127.0.0.1:9000; naquele momento muito específico .

• seus registros de erros iniciais contam tudo:

.

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???

do meu pov limitado eu sugeriria:

• reinicie seu fastcgi_process / server
• verifique seu log de acesso
• ativar o log de depuração

Sei que esse tópico é antigo, mas continua aparecendo ocasionalmente; portanto, procurando respostas na Web, criei as três possibilidades a seguir:

1. Às vezes, um erro de programação às vezes falha o php-fpm, o que significa que a conexão com o nginx será cortada. Isso geralmente deixa pelo menos alguns logs em torno e / ou core dumps, que podem ser analisados ​​posteriormente.
2. Por alguma razão, o PHP não está conseguindo gravar um arquivo de sessão (normalmente session.save_path = "/var/lib/php/sessions":). Isso pode ser permissões ruins, propriedade inadequada, usuário / grupo inadequado ou problemas mais esotéricos / obscuros, como a falta de inodes nesse diretório (ou até mesmo um disco completo!). Isso geralmente não deixa muitos despejos de núcleo e possivelmente nem mesmo nada nos logs de erro do PHP.
3. Ainda mais difícil de depurar: uma extensão está se comportando mal (ocasionalmente atingindo algum tipo de limite interno ou um bug que não é acionado o tempo todo), segfaulting e desativando o processo php-fpm - fechando assim a conexão com o nginx . Os culpados comuns são APC, memcache / d etc. (no meu caso, era a extensão New Relic), então a idéia aqui é desativar cada extensão até que o erro desapareça.

Continuou recebendo isso também. Resolva-o aumentando o opcachelimite de memória, se você o usar (substituindo o APC). Parece que o PHP-FPM eliminou as conexões sempre que o cache ficou muito cheio. Esta também é a razão pela qual a resposta do shgnInc o corrige por um curto período de tempo.

Portanto, encontre o arquivo /etc/php5/fpm/php.ini(ou equivalente em sua distribuição) e aumente memory_consumptionpara qualquer nível que seu site precise. Desabilitar opcachetambém pode funcionar.

[opcache]
opcache.memory_consumption = 196 

Você pode considerar esse git no github: https://gist.github.com/amichaelgrant/90d99d7d5d48bf8fd209

Eu encontrei uma situação semelhante, quando verifiquei os logs de erro dos meus servidores upstream, eles estavam relatando algum erro ulimit, então aumentei para 1000000 (nas caixas upstream e nginx) e tudo funcionou bem

No meu caso do mesmo problema, basta reiniciar o php-fpmserviço para que ele seja resolvido.

sudo service php5-fpm restart

Ou, algumas vezes, esse problema ocorre por causa de muitos pedidos. Por padrão, pm.max_requestsem php5-fpm talvez seja 100 ou menos.

Para resolvê-lo, aumentar seu valor depende das solicitações do seu site, por exemplo, 500.

E depois que você tiver que reiniciar o serviço

No meu caso, desabilitar a extensão xdebug ajudou.

Eu apenas tive um problema semelhante:

Você se conecta ao php-fpm na porta 9000. (fastcgi: //127.0.0.1: 9000)

A configuração padrão no Ubuntu no meu servidor é:

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

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

você precisa alterar isso para:

listen = 0.0.0.0:9000

No meu caso, atualizei meu servidor há 1 mês e meio, substituindo minha configuração de custo pelo padrão. Agora, tendo reiniciado o php-fpm, esse erro entrou em vigor com atraso.

Para mim, era o servidor ficando sem memória e o php-fpm sendo morto pelo OOM killer. A solução foi aumentar a quantidade de memória do servidor.

Para mim, foi porque o php-fpm estava atingindo o max_childrenlimite. O log php-fpm do pool em questão me indicou a direção certa

Esse problema também pode surgir se um processo PHP-FPM exceder o limite de memória alocado. Quando isso acontece, a conexão entre o NGINX e o PHP-FPM é cortada e o NGINX retorna a 502 Bad Gateway. O limite de memória do processo PHP-FPM é controlado pela memory_limitvariável Isso pode ser definido php_admin_value[memory_limit]no arquivo de configuração do PHP-FPM.

É importante observar que o limite de memória se aplica por script . Com nprocessos PHP-FPM, o uso total de memória pode ser de até memory_limit * n. Certifique-se de verificar se a sua máquina possui espaço suficiente na memória!