O nginx para de enviar tráfego para servidores php que não respondem?

1

Estamos executando um site na AWS com uma configuração específica: Um ELB divide a carga em instâncias de 2 x t2.medium executando nginx. A partir daí, o tráfego do PHP é dividido em dois fluxos (frontend e API), ambos para os ELBs internos que estão à frente dos nossos servidores PHP. Para o registro, temos 2 servidores PHP frontend (t2.medium) e 3 servidores PHP API (m4.large). Todos executando a mesma versão do PHP-FPM na porta 9000.

Tudo funcionou bem até alguns dias atrás. Por algum motivo, ainda a ser determinado, o tráfego nos servidores da API do PHP apenas morre e somente uma reinicialização do nginx o traz de volta à vida.

Nós assumimos que podemos ter algum processo de execução longa fazendo com que um dos servidores PHP fique ocupado e tudo desce a partir daí. No entanto, o uso da CPU é bastante constante em todos os servidores PHP até o momento em que eles pararam de responder. O PHP-FPM ainda está em execução e a carga nos servidores ngnix ainda é muito baixa. As respostas recebidas pelos clientes são 504 e é isso que vejo no log de erros do nginx: 2016/10/04 14:34:25 [error] 17661#0: *2309784 connect() failed (113: No route to host) while connecting to upstream, client: xxx.xxx.xxx.xxx, server: api.mywebsite.com, request: "GET /some/route HTTP/1.1", upstream: "fastcgi://internalip:9000", host: "api.mywebsite.com"

nginx.conf

worker_processes 4;
worker_connections 19000;

conf do site nginx

location ~ \.php$ {
    try_files $uri =404;

    fastcgi_buffer_size 512k;
    fastcgi_buffers 16 256k;
    fastcgi_busy_buffers_size 1024k;

    include fastcgi_params;

    fastcgi_pass route53-php:9000;
    fastcgi_index index.php;

    fastcgi_param REQUEST_URI /api$request_uri;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

www.conf

listen = 9000
pm = dynamic
pm.max_children = 50
pm.start_servers = 25
pm.min_spare_servers = 25
pm.max_spare_servers = 25
pm.max_requests = 500

Como a configuração está longe de ser trivial, eu me pergunto se o bloco de localização do PHP está configurado corretamente. Também pode ser o tamanho dos servidores usados, mas o uso da CPU é muito baixo.

    
por Alex 04.10.2016 / 17:50

1 resposta

0

Bem, acontece que esse é um problema comum com o nginx falando com um ELB interno da AWS. Depois de um pouco mais de googling, eu encontrei esta pergunta: Alguns As configurações do proxy reverso nginx param de funcionar uma vez por dia e adicionar o resolvedor ajudou - eu não tive nenhum tempo de inatividade por 3 dias agora.

Também é interessante ressaltar que cada artigo que encontrei está falando sobre proxy_pass , mas parece funcionar bem com fastcgi_pass também.

Espero que isso ajude alguém na mesma situação!

    
por 18.10.2016 / 11:37