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.