Erro Nginx + php-fpm "504 Gateway Time-out" com carga quase zero (em um servidor de teste)

29

Após a depuração por 6 horas - eu estou desistindo disso: |

Temos um nginx + php-fpm + mysql na LAN com quase 100 wordpress (criados e usados ​​por diferentes designers / desenvolvedores, todos trabalhando na configuração de wordpres de teste)

Estamos usando o nginx sem problemas por muito tempo.

Hoje, de repente, o nginx começou a retornar "504 Gateway Time-out" do nada ...

Eu verifiquei o log de erro do nginx para um host virtual ...

2010/09/06 21:24:24 [error] 12909#0: *349 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET /favicon.ico HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 21:25:11 [error] 12909#0: *349 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET /favicon.ico HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 21:25:11 [error] 12909#0: *443 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET /info.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 21:25:12 [error] 12909#0: *443 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET /favicon.ico HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 22:08:32 [error] 12909#0: *1025 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 22:09:33 [error] 12909#0: *1025 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET /favicon.ico HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 22:09:40 [error] 12909#0: *1064 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET /info.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 22:09:40 [error] 12909#0: *1064 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET /favicon.ico HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 22:24:44 [error] 12909#0: *1313 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 22:24:53 [error] 12909#0: *1313 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET /favicon.ico HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"

Ao executar o php-fpm na porta 9000 via modo TCP, executei "netstat | grep 9000" e notei algo incomum ... (Colando aqui uma saída parcial para facilitar a leitura)

tcp        9      0 localhost:9000          localhost:36094         CLOSE_WAIT  14269/php5-fpm  
tcp        0      0 localhost:46664         localhost:9000          FIN_WAIT2   -               
tcp     1257      0 localhost:9000          localhost:36135         CLOSE_WAIT  -               
tcp     1257      0 localhost:9000          localhost:36125         CLOSE_WAIT  -               
tcp        9      0 localhost:9000          localhost:36102         CLOSE_WAIT  14268/php5-fpm  
tcp        0      0 localhost:46662         localhost:9000          FIN_WAIT2   -               
tcp      745      0 localhost:9000          localhost:46644         CLOSE_WAIT  -               
tcp        0      0 localhost:46658         localhost:9000          FIN_WAIT2   -               
tcp     1265      0 localhost:9000          localhost:46607         CLOSE_WAIT  -               
tcp        0      0 localhost:46672         localhost:9000          ESTABLISHED 12909/nginx: worker
tcp     1257      0 localhost:9000          localhost:36119         CLOSE_WAIT  -               
tcp     1265      0 localhost:9000          localhost:46613         CLOSE_WAIT  -               
tcp        0      0 localhost:46646         localhost:9000          FIN_WAIT2   -               
tcp     1257      0 localhost:9000          localhost:36137         CLOSE_WAIT  -               
tcp        0      0 localhost:46670         localhost:9000          ESTABLISHED 12909/nginx: worker
tcp     1265      0 localhost:9000          localhost:46619         CLOSE_WAIT  -               
tcp     1336      0 localhost:9000          localhost:46668         ESTABLISHED -               
tcp        0      0 localhost:46648         localhost:9000          FIN_WAIT2   -               
tcp     1336      0 localhost:9000          localhost:46670         ESTABLISHED -               
tcp        9      0 localhost:9000          localhost:36108         CLOSE_WAIT  14274/php5-fpm  
tcp     1336      0 localhost:9000          localhost:46684         ESTABLISHED -               
tcp        0      0 localhost:46674         localhost:9000          ESTABLISHED 12909/nginx: worker
tcp     1336      0 localhost:9000          localhost:46666         ESTABLISHED -               
tcp     1257      0 localhost:9000          localhost:46648         CLOSE_WAIT  -               
tcp     1336      0 localhost:9000          localhost:46678         ESTABLISHED -               
tcp        0      0 localhost:46668         localhost:9000          ESTABLISHED 12909/nginx: wo             

Existem muitos pares "CLOSE_WAIT" e "FIN_WAIT2", conforme destacado abaixo (na saída acima):

tcp     1337      0 localhost:9000          localhost:46680         CLOSE_WAIT  -               
tcp        0      0 localhost:46680         localhost:9000          FIN_WAIT2   -

Observe a porta 46680 acima.

Eu habilitei o log de erros do mysql slow query, mas não funcionou.

A partir de agora, reinicie o php5-fpm a cada minuto através de um cronjob (veja o comando abaixo) mantendo tudo funcionando "sem problemas", mas eu odeio patchwork e quero resolver isso ...

1 * * * * service php5-fpm restart > /dev/null

Pesquisei bastante no Google - não recebi ajuda. Como mencionado, este é um servidor de teste na LAN, a carga da CPU nunca ultrapassa 0,10 e o uso da memória também é inferior a 25% (o sistema possui 2 GB de RAM e o servidor ubuntu instalado). pelo menos dê uma dica.

Agradecemos antecipadamente a ajuda.

-Rahul

(note - isto é republicado em - http://forum.nginx.org/read.php?11,127694 )

Atualização: Encontrei a resposta, publicada abaixo.

rahul286
fonte

Respostas:

31

Encontrei resposta na minha postagem no fórum nginx - http://forum.nginx.org/read.php?2,127854

A resposta, no meu caso, é definir:

request_terminate_timeout=30s

na configuração do php-fpm (geralmente /etc/php5/fpm/php-fpm.conf)

Observe que você também pode usar valores diferentes de 30s.

Eu o usei para corresponder ao meu valor no php.iniarquivo principal, que é:

max_execution_time = 30

Obrigado a todos. :-)

rahul286
fonte
5
Essa configuração também pode ser encontrada no arquivo www.conf. Obrigado pela resposta, porém, isso parece ter funcionado.
precisa saber é
2
Esta é uma diretiva no nível do pool, você receberá uma mensagem de erro ao tentar colocá-la na seção php-fpm.conf [global]. Ele funciona lá apenas se você também tiver suas configurações de pool. Também: request_terminate_timeout docs .
30135 tanius
Se esta é a resposta correta que eu realmente preciso, nesta sexta-feira será o melhor de 2015 ainda.
Philip
2
Descobri que a inserção request_terminate_timeout=30sno meu php-fpm.confarquivo causou um erro (111 Conexão recusada). Quando o mudei para o meu www.confarquivo, ele funcionou.
AJB
No CentOS 7.2 ao usar php7, request_terminate_timeout está localizado em: /etc/php-fpm.d/www.conf
nadavkav
16

Aqui como ele resolveu meu problema:

faça as seguintes alterações no /etc/nginx/nginx.conf na http {section

proxy_connect_timeout  600s;
proxy_send_timeout  600s;
proxy_read_timeout  600s;
fastcgi_send_timeout 600s;
fastcgi_read_timeout 600s;

e depois reinicie o nginx

/etc/init.d/nginx restart

Vijay Kumar
fonte
2
Sim, isso realmente não parece ter nada a ver com o problema que a pessoa que faz a pergunta tem.
precisa
3
Mas, felizmente, isso é o que eu precisava :)
Luchaninov
Isso não corrigiu meu problema, mas me permitiu ver o erro real em vez da mensagem de tempo limite, o que me levou ao problema real.
Michael
4

Se você estiver usando o php 5.3, aumente a lista de pendências.

Se você estiver usando o php 5.2, faça o backport do patch para aumentar o tamanho da lista de pendências de 128.

Além disso, use um soquete unix em vez de um soquete TCP. unix: /tmp/php5-cgi.sock (ou o caminho relevante)

karmawhore
fonte
Eu teria que concordar, especialmente com o uso do soquete unix.
Matt
Obrigado karmawhore pela resposta. Encontrei uma solução na lista de endereços nginx.
rahul286
@ rahul286 qual resposta? Estou interessado!
Breiti
@breiti ver meu anser abaixo - serverfault.com/a/179136/17440 #
rahul286
3

Ótimo obrigado

request_terminate_timeout = 30s

Funciona perfeitamente para mim

mas tive que inserir a linha neste arquivo: "/etc/php5/fpm/pool.d/www.conf", ou seja, na "Seção Trabalhador".

PHP 5.3.21-1 - Wordpress 3.5.1

http://php-fpm.org/wiki/Configuration_File

Franck
fonte
Eu tive uma combinação de fatores que acabam causando o erro 502 que sua receita fez o truque de mágica! muito obrigado!
Jorge Vicente Mendoza
2

no meu caso (mesma mensagem de erro do nginx), alguns scripts php problemáticos não terminam para executar e aguardam algo, resultando em não mais filhos php5-fpm para o nginx escolher.

consertar:

  1. adicionar prazo de execução outro mencionado neste post. request_terminate_timeout=30s
  2. aumentar o número de filhos. e tudo funcionou como um encanto. pm.max_spare_servers=16 pm.min_spare_servers=2

agora tudo funcionava como um encanto.

c2h2
fonte
Eu tive um longo pedido de conexão externa em meu script php. Procure essas tarefas de longa duração e coloque um tempo limite para elas.
Ali Nadalizadeh
1

Eu tive o mesmo problema e resolvi removendo completamente o Apache:

yum remove httpd

Depois disso, recomendo restaurar o PHP e o NGINX:

/etc/init.d/nginx restart
/etc/init.d/php-fpm restart
Nikolay
fonte
1
Não tínhamos apache no nosso servidor. Fico feliz em conhecer o seu caso, pois pode nos ajudar no futuro.
rahul286
0

Para mim, o mesmo problema ocorreu após a remoção do rabbitmq do servidor. Nada acima foi útil, a reinstalação de todos os módulos php5 resolveu o problema. Eu tinha o Debian 8.2 nesse servidor. A esperança será útil para alguém.

Cometa Taggart
fonte
-1

Isso também pode ajudar as pessoas:

Dependendo da configuração, você deve observar os parâmetros de configuração do fastcgi e o php ... no meu caso (estou usando apache2 + php5-fpm) e o tempo máximo de execução também depende de quanto tempo o módulo fastcgi aguarda resposta ( -idle-timeout) ...

http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html#FastCgiExternalServer

farinspace
fonte
por que usar apache2 ?? Quero dizer, você pode usar o nginx diretamente para interagir com php5-fpm. Não é necessário usar o Apache quando você tiver o nginx!
precisa saber é o seguinte
Se você estiver usando o nginx, se outros NÃO estiverem usando o nginx, espero que isso os ajude. :-) ... me deparei com esta página procura de Apache2 + php5-fpm pergunta relacionada
farinspace
Está bem. Eu pensei que você estivesse usando o Nginx com Apache para scripts PHP, como algumas pessoas usaram no passado.
rahul286