Início / server / Perguntas / 543999
Accepted
Nigel Alderton
Asked: 2013-10-06 03:28:47 +0800 CST

104: Conexão redefinida por peer ao ler o cabeçalho de resposta do upstream (Nginx)

  • 772

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

Aproximadamente 4 em cada 5 solicitações do 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 fornecer 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 .confpara este 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;
}
nginx

12 respostas

  1. Best Answer

    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 as conexões de rede?
    • você pode confirmar/negar uma mudança na contagem de visitantes naquele dia?

    O que isso significa:

    • seu processo fastcgi não é acessível pelo nginx; ou para abrandar ou não correspondendo em tudo. gateway ruim significa: nginx não pode fastcgi_pass para esse recurso definido 127.0.0.1:9000; naquele momento muito específico .

    • seus logs de erros iniciais dizem 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 sugiro:

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

  2. Eu sei que este tópico é antigo, mas ainda continua aparecendo ocasionalmente, então, procurando respostas na web, encontrei as três possibilidades a seguir:

    1. Um erro de programação às vezes é a segmentação do php-fpm, que por sua vez significa que a conexão com o nginx será cortada. Isso geralmente deixará pelo menos alguns logs e/ou core dumps, que podem ser analisados ​​posteriormente.
    2. Por alguma razão, o PHP não está conseguindo escrever um arquivo de sessão (geralmente: session.save_path = "/var/lib/php/sessions"). Isso pode ser permissões ruins, propriedade ruim, usuário/grupo incorreto ou problemas mais esotéricos/obscuros, como ficar sem inodes nesse diretório (ou até mesmo um disco cheio!). Isso geralmente não deixará muitos despejos de núcleo e possivelmente nem mesmo nada nos logs de erros do PHP.
    3. Ainda mais complicado 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), falhando na segmentação e trazendo o processo php-fpm para baixo - fechando assim a conexão com o nginx . Os culpados usuais são APC, memcache/d, etc. (no meu caso foi a extensão New Relic), então a ideia aqui é desligar cada extensão até que o erro desapareça.
    • 17

  3. Continuava recebendo isso também. Resolvido aumentando o opcachelimite de memória, se você usá-lo (substituto para APC). Parece que o PHP-FPM derrubou 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 o nível que seu site precisar. A desativação opcachetambém pode funcionar.

    [opcache]
opcache.memory_consumption = 196
    • 10

  4. No meu caso do mesmo problema, apenas reinicio o php-fpmserviço para que ele seja resolvido.

    sudo service php5-fpm restart

    Ou algumas vezes esse problema acontece por causa de grandes solicitações. Por padrão pm.max_requests, o php5-fpm talvez seja 100 ou menos.

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

    E depois disso você tem que reiniciar o serviço

    • 6

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

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

    • 2

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

    • 2

  7. Esse problema também pode surgir se um processo PHP-FPM exceder seu limite de memória alocado. Quando isso acontece, a conexão entre o NGINX e o PHP-FPM é cortada e o NGINX retorna um arquivo 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 sua máquina tem espaço de memória suficiente!

    • 2

  8. Acabei de ter um problema semelhante:

    Você se conecta php-fpmna 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ê tem que mudar isso para:

    listen = 0.0.0.0:9000

    No meu caso, atualizei meu servidor 1 1/2 meses atrás, substituindo minha configuração personalizada pelo padrão. Agora, tendo reiniciado, php-fpmeste erro entrou em vigor com atraso.

    • 1

  9. Para mim, foi 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

  10. Para mim foi porque o php-fpm estava atingindo o max_childrenlimite. O log php-fpm para o pool em questão me apontou na direção certa

    • 1

relate perguntas