Eu tenho um servidor rodando em um Linode com Ubuntu 10.04 LTS, Nginx 0.7.65, MySQL 5.1.41 e PHP 5.3.2 com PHP-FPM.
Há um blog WordPress, atualizado para o WordPress 3.2.1 recentemente.
Eu não fiz alterações no servidor (exceto a atualização do WordPress) e enquanto ele estava rodando bem, alguns dias atrás eu comecei a ter downtimes.
Eu tentei resolver o problema e, verificando o error_log, vi muitos tempos limites e mensagens que pareciam estar relacionados a tempos limite. O servidor está registrando atualmente esse tipo de erro:
2011/07/14 10:37:35 [warn] 2539#0: *104 an upstream response is buffered to a temporary file /var/lib/nginx/fastcgi/2/00/0000000002 while reading upstream, client: 217.12.16.51, server: www.example.com, request: "GET /page/2/ HTTP/1.0", upstream: "fastcgi://127.0.0.1:9000", host: "www.example.com", referrer: "http://www.example.com/"
2011/07/14 10:40:24 [error] 2539#0: *231 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 46.24.245.181, server: www.example.com, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.example.com", referrer: "http://www.google.es/search?sourceid=chrome&ie=UTF-8&q=example"
e até mesmo viu esta discussão anterior sobre o serverfault com uma possível solução: para editar /etc/php/etc/php-fpm.conf e alterar
request_terminate_timeout=30s
em vez de
;request_terminate_timeout= 0
O servidor funcionou por algumas horas e depois quebrou novamente. Eu editei o arquivo novamente para deixá-lo como estava, e reiniciei novamente o php-fpm ( service php-fpm restart ) mas sem sorte: o servidor funcionou por alguns minutos e voltou ao problema várias vezes. O estranho é que, embora os serviços estejam rodando, htop mostra que não há carga de CPU (veja imagem) e eu realmente não sei como resolver o problema.
Osarquivosdeconfiguraçãoestãoempastebin
Oarquivophp-fpm.conf está aqui
A /etc/nginx/nginx.conf está aqui
A /etc/nginx/sites-available/www.example.com está aqui
Você já tentou em vez de "upstream" -ing no nginx.conf fazendo algo como:
# Pass PHP scripts to PHP-FPM
location ~* \.php$ {
try_files $uri /index.php;
fastcgi_index index.php;
fastcgi_pass 127.0.0.1:9000;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
}
Dê uma olhada aqui link
and restarted again php-fpm [...] the server worked for a few minutes and back to the problem over and over
Mas não é o tempo limite. Aumentar o tempo limite apenas dá ao php mais tempo para processar uma única solicitação - o que pode mascarar os sintomas, mas não é a solução correta.
O log do php-fpm deve explicar por que o servidor está com dificuldades aparentes; na minha experiência (obviamente, na ausência de informações, isso é um palpite) o arquivo de log do php-fpm conterá entradas como esta:
#/var/log/php5-fpm.log
[19-Oct-2014 06:25:10] NOTICE: error log file re-opened
[19-Oct-2014 17:46:56] WARNING: [pool www] seems busy (you may need to increase
pm.start_servers, or pm.min/max_spare_servers), spawning 1 children, there are
1 idle, and 5 total children
...
Se houver apenas algumas entradas de log como as acima, isso não é um grande problema. Se houver muitos e somente minutos ou segundos de intervalo - então o php-fpm tem recursos insuficientes para a carga que está sendo solicitada para lidar com isso.
Isso não é incomum, porque um arquivo de configuração padrão dist php-fpm conterá algo semelhante a isto:
# /etc/php5/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
O que significa que o php-fpm irá apenas lidar com um máximo de 5 pedidos em paralelo .
Especialmente com algo como wordpress, que para uma única página html entrega um grande número de pedidos subseqüentes (imagens, css, arquivos js etc.) também para php - é fácil para um grande e fila crescente de solicitações para formar de forma que, para qualquer solicitação, ele deve primeiro aguardar que as solicitações em andamento e já em espera sejam processadas primeiro. Isso leva a atrasos (ele aparece como tempo de espera em qualquer ferramenta de criação de perfil de navegador) e freqüentemente leva a um grande número de tempos de espera.
Observe também que um grande número de 404s (pedidos de qualquer coisa que não exista) é uma maneira fácil de exagerar as limitações de qualquer servidor - verifique e corrija quaisquer 404s que o site esteja gerando.
Se o problema é que o php-fpm tem poucos processos de servidor em execução - apenas os aumente. Os números a serem utilizados dependem do hardware do servidor em que são implantados; aqui está uma sugestão:
# /etc/php5/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 20
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 15
Isso permitiria atender 20 solicitações em paralelo - e deve aliviar qualquer problema sem causar problemas no servidor.
Em caso de dúvida, há uma regra simples a seguir ao alterar a configuração do php-fpm: