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

Question

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

Nós temos um nginx + php-fpm + mysql na LAN com quase 100 wordpress (criado e usado por diferentes designers / desenvolvedores, todos trabalhando em configuração 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 erros 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"

Enquanto executo o php-fpm na porta 9000 via TCP, executei "netstat | grep 9000" e notei algo incomum ... (colando saída parcial aqui 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 "CLOSE_WAIT" & "FIN_WAIT2" pares como destacado abaixo (na saída acima):

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

Por favor, observe a porta 46680 acima.

Eu ativei o log de erro de consultas lentas do mysql, mas não funcionou.

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

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

Eu pesquisei extensivamente no Google - não tive ajuda. Como mencionado, este um servidor de teste na LAN, a carga da CPU nunca é ultrapassada 0,10 e o uso da memória também é inferior a 25% (o sistema tem 2 GB de RAM e o servidor Ubuntu instalado) Então, se você achar confuso o tempo para me ajudar, por favor, dê uma dica ao menos.

Agradecemos antecipadamente pela ajuda.

-Rahul

(nota - esta é reposting de - link )

Atualização: encontrei a resposta, que é postada abaixo.

    

Answer 1

Encontrei resposta na minha postagem no fórum do nginx - link

A resposta, no meu caso, é definir:

request_terminate_timeout=30s

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

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

Eu usei para corresponder ao meu valor no arquivo principal php.ini , que é:

max_execution_time = 30

Obrigado a todos. : -)

    

Answer 2

Veja como isso resolveu meu problema:

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

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

e reinicie o nginx

/etc/init.d/nginx restart

    

Answer 3

Se você estiver usando o php 5.3, aumente o backlog.

Se você estiver usando o php 5.2, retroceda o patch para aumentar o tamanho do backlog de 128.

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

    

Answer 4

Ótimo, obrigado

request_terminate_timeout = 30s

Funciona perfeitamente para mim

mas, eu tive que inserir a linha neste arquivo: "/etc/php5/fpm/pool.d/www.conf", isto é, na "Seção de Trabalho".

PHP 5.3.21-1 - Wordpress 3.5.1

link

    

Answer 5

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

consertar:

1. adicionar limite de tempo de execução outro mencionado neste post. %código%
2. aumenta o número de filhos. e tudo funcionou como um encanto. request_terminate_timeout=30s pm.max_spare_servers=16

agora tudo funcionou como um encanto.

    

Answer 6

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

yum remove httpd

Depois disso, eu recomendo fazer o reinício tanto do PHP quanto do NGINX:

/etc/init.d/nginx restart
/etc/init.d/php-fpm restart

    

Answer 7

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

    

Answer 8

Isso também pode ajudar as pessoas:

Dependendo da sua configuração, você deve olhar para os parâmetros de configuração fastcgi, assim como php ... no meu caso (estou usando apache2 + php5-fpm) e max_execution time também depende de quanto tempo o módulo fastcgi aguarda para resposta (-idle-timeout) ...

link