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


44

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

O que mudou naquele dia? Atualizou seu aplicativo ou PHP? Qual é a sua aplicação? Você ativou a depuração no php-fpm?
Pothi Kalimuthu 5/10

Nada foi mudado naquele dia. A configuração do servidor não foi alterada, nem houve scripts PHP. Não há espaço em disco. Meu aplicativo é apenas um conjunto de PHPscripts. Eu não estou usando php-fpm, eu só estou correndo php-fastcgifazendo php-cgi -b 127.0.0.1:9000. Trabalha há 3 anos sem falhas. Não sei por que ele desenvolveu esse problema.
Nigel Alderton 05/10

Recentemente, tive um problema semelhante em que o nginx estava reclamando da redefinição de conexão por pares ao ler o cabeçalho de resposta do upstream; no meu caso, era o uWSGI que era o problema real; reiniciar o uWSGI corrigiu o problema para mim, por que isso estava acontecendo questão.
APZ 26/01

Seu serviço upstream ( php-cgi -b 127.0.0.1:9000) está falhando intermitentemente, talvez devido ao aumento do tráfego e à falta de recursos.
LinuxDevOps

Respostas:


22

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

Está bem. O que meus servidores da web estão me dizendo?
Nigel Alderton 31/03

veja minha edição (o que significa)
aquele cara de lá

2
Entendo, então Gatewayneste caso é o servidor PHP. Obrigado.
Nigel Alderton 31/03

restart your fastcgi_process / serveré o que me ajudou, thans
realtebo 8/04

11

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.

+1 No meu caso, era o número 1 - erro de programação.
Nimbuz 6/09/16

Encontramos este erro e desabilitar a extensão PHP da New Relic APM revelou um erro mais específico que nos permitiu rastrear o problema: [29-Jan-2018 16:47:48 UTC] PHP Erro fatal: tamanho de memória permitido de 805306368 bytes esgotado (tentou alocar 262144 bytes) em vendor / magento / module-configurable-product / Pricing / Price / ConfigurableRegularPrice.php na linha 142 [29-Jan-2018 16:47:48 UTC] PHP Erro fatal: tamanho de memória permitido 805306368 bytes esgotados (tentou alocar 323584 bytes) em Desconhecido na linha 0 Meu palpite é que a New Relic engasgou com o caminho "Desconhecido".
Erik Hansen

7

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 


2

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


2

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


idem, no meu caso, defini uma condição para um ponto de interrupção e, nesse momento, desabilitei o ponto de interrupção do erro.
roman204 16/04

1

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.


1

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.


1

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


0

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!

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.