Nós administramos uma plataforma de aprendizado para escolas primárias aqui no Reino Unido e tudo correu muito bem. No entanto, por volta das 4 da tarde de segunda a sexta-feira, vemos o mesmo problema - 1-2 encadeamentos PHP irão atingir 100% da CPU e gradualmente começarão a consumir RAM até que o (s) servidor (es) caiam.
98% + dos nossos pedidos são HTTPS, eles entram no nosso balanceador de carga da Camada 7, que descriptografa os dados SSL, adiciona o cabeçalho X-HTTP-Forwarded-For e encaminha os dados para um servidor de aplicativos (temos dois deles no momento ) na porta 80. Nossos servidores de aplicativos têm o Varnish na porta 80 que recebe a solicitação do balanceador de carga e passa a solicitação para o Nginx na porta 81. O Nginx então calcula qual 'vhost' precisa usar e transmite qualquer processamento PHP através de PHP-CGI que está escutando em um soquete (gerenciado através de spawn-fcgi). Há uma instância do Memcached rodando também, o MySQL roda em uma configuração separada de servidor / escravo.
Durante todo o dia, a carga normalmente não ultrapassará 0,8 em qualquer um dos servidores de aplicativos, no entanto, por volta das 4h, nosso problema surge. Eu consegui executar strace em alguns dos threads reais quando eles causam o problema e eu sempre vejo a mesma coisa:
stat("/usr/share/zoneinfo/Europe/London", {st_mode=S_IFREG|0644,st_size=3661, ...}) = 0
stat("/usr/share/zoneinfo/Europe/London", {st_mode=S_IFREG|0644,st_size=3661, ...}) = 0
Isso é repetido infinitamente e nunca pára até você SEGKILL o processo ou oomkiller mata-lo. Não há tarefas agendadas agendadas para execução naquele momento e não tenho como ver exatamente qual solicitação Nginx está associada ao processo PHP que está sendo executado.
Nós estamos rodando o PHP 5.3.14 que atualizamos para o 5.3.8 na semana passada para descartar a versão mais antiga sendo o problema. Esse problema já está acontecendo há alguns meses e não temos ideia do que está causando isso. Nós implantamos nosso software com muita freqüência, por isso é difícil rastrear uma versão específica que possa ter iniciado o problema - especialmente porque não sabemos a data da primeira ocorrência deste problema. Varnish é a versão 3.0.1, o Nginx é 1.0.6 (o que eu entendo tem cerca de um ano agora), nossos servidores estão rodando o CentOS release 5.7 (Final) eles têm Intel i3 540s a 3.07Ghz e 8GB de RAM.
Existe uma discussão na lista de discussão do Debian sobre algo muito similar, você pode encontrar esse aqui .
Alguém viu algo assim no passado? Alguém tem alguma ideia ou sugestão? Existe uma maneira de vincular uma solicitação Nginx diretamente a um thread do PHP? Existe uma maneira melhor de ver o que o processo PHP está fazendo? (Eu vi o GDB mencionado, embora tenha que recompilar o PHP)
Obrigado!
Descobri qual era o problema, era o Internet Explorer. Houve uma má referência a um arquivo .htc em nosso CSS que, por algum motivo, estava sendo enviado para o PHP para ser processado. O PHP não sabia o que fazer com um arquivo .htc e acabou ficando louco e consumindo todos os recursos disponíveis no servidor.
Com informações adicionais do comentário, acho que podemos assumir com segurança que o problema ocorre durante o pico de carga - número de picos diários dos usuários on-line. Sem tempo exato fixo, às vezes acontece em outros momentos e outros dias efetivamente descartam coisas como o cron job sobrecarregando recursos.
Pode parecer loucura, mas comece aumentando o limite de conexões máximas do MySQL - Eu vi coisas estranhas acontecendo com o PHP rodando como FCGI quando o limite de conexão foi excedido, não muito diferente do problema que você está enfrentando.
Tags php nginx timezone centos spawn-fcgi