Como depurar os tempos limite do apache?

Question

Eu rodei uma aplicação web PHP em um servidor Apache 2.2 (Ubuntu Server 10.04, 8x2GHz, 12Gb RAM) usando prefork . A cada dia, o Apache recebe cerca de 100 mil a 200 mil solicitações, dessas cerca de 100 a 200 acessos, o limite de tempo limite (cerca de uma em cada mil), praticamente todas as outras solicitações são atendidas bem abaixo do tempo limite.

O que posso fazer para descobrir por que isso acontece? Ou é normal que algumas pequenas partes de todas as solicitações expirem?

Isso foi o que eu fiz até agora:

Comopodeservisto,hápouquíssimassolicitaçõesentreolimitedetempolimiteeasolicitaçãomaisrazoável.Atualmente,olimitedetempolimiteédefinidopara50segundos,anteriormenteeradefinidopara300eaindaeraamesmasituaçãocomalgunstemposlimitee,emseguida,umaenormelacunaatéasoutrassolicitações.

TodasassolicitaçõescomtempolimitesãoAJAXdesolicitações,masagrandemaioriadelasé,talvezsejamaisumacoincidência.OcódigoderetornodoApacheé200,masolimitedetempolimiteéatingidoclaramente.ElessãodeumaamplagamadeIPsdiferentes.

Euolheiparaospedidosqueexpiramenãohánadaespecialsobreeles,seeufizerosmesmospedidosqueelespassamemmenosdeumsegundo.

Eutenteiolharparaosdiferentesrecursosparaverseconsigoencontraracausa,massemsorte.Hásempremuitamemórialivre(omínimoédecercade3GBlivre),acargaàsvezeschegaa1,4eautilizaçãodaCPUpara40%,masmuitosdostemposlimiteacontecemquandoacargaeautilizaçãodaCPUsãobaixas.Agravação/leituradediscosépraticamenteconstanteduranteodia.NãoháentradasnologdeconsultaslentasdoMySQL(configuradopararegistrarqualquercoisaacimade1segundo),umasolicitaçãonousaessasmuitasgravações/leiturasdebancodedados.

Azul é a utilização da CPU, que tem um pico de 40%, e a carga marrom é de pico com 1,4. Assim, podemos ver que temos tempos limite mesmo com baixa utilização / carga da CPU (os picos de dez segundos correspondem bem à utilização da CPU, mas isso é outro problema, tenho maiores esperanças de descobrir o que pode estar causando isso).

Não há erros no log de erros do Apache e eu não o vi chegar a mais de 200 processos ativos do Apache.

Configurações do servidor:

Timeout 50 
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 2

<IfModule mpm_prefork_module>
    ServerLimit     350
    StartServers        20
    MinSpareServers     75
    MaxSpareServers     150
    MaxClients          320
    MaxRequestsPerChild 5000
</IfModule>

Atualização:

Eu atualizei para o Ubuntu 12.04.1, apenas no caso, nenhuma mudança. Eu adicionei mod_reqtimeout com configurações:

RequestReadTimeout header=20-40,minrate=500
RequestReadTimeout body=10,minrate=500

Agora quase todos os tempos limite acontecem em 10 segundos, um ou dois em 20 segundos. Eu entendo que isso significa que na maioria das vezes está recebendo o corpo da solicitação que é problemático receber? O corpo da solicitação nunca deve ser maior que algumas centenas de bytes. Eu monitorei o tráfego de rede em uma base de 1 segundo e nunca fica acima de 1Mbit / se eu não vejo nenhum rxerrs ou rxdorps, considerando que o servidor está em uma linha de 1Gbit / s não soa como o HopelessN00b postou sobre. Poderia ser apenas um caso de algumas conexões ruins com o usuário?

Para os picos a cada hora (eles parecem vagar um pouco, nos gráficos acima eles estão em 33 minutos depois da hora, agora eles estão em 12 minutos), eu tentei ver se há alguma coisa correndo periodicamente (crons etc), mas não encontrou nada. A coleta de lixo do PHP é executada duas vezes a cada hora, mas não no momento dos picos, ainda tentei desabilitá-la, mas não faz diferença.

Eu usei dstat com --top-cpu e top para ver os processos no momento dos picos e tudo o que aparece é o apache trabalhando duro por alguns segundos, mas nenhum outro processo está usando cpu significativo. / p>

Eu fiz um gráfico com zoom dos picos:

Para mim, parece que o apache pára por alguns segundos e, em seguida, trabalha duro para processar as solicitações recebidas durante a parada. O que pode causar tal parada, ou eu estou interpretando mal?

    

Answer 1

A primeira coisa que observo, olhando para o seu primeiro gráfico, parece haver uma lentidão de hora em hora (ocorrendo em torno de 40 minutos após a hora), o que pode estar contribuindo para o problema. Você deve dar uma olhada nos agendadores de tarefas no sistema operacional / banco de dados.

Com base nos dados que você forneceu, minha próxima etapa será analisar a frequência dos tempos de resposta (número de respostas no eixo Y versus duração em X), mas incluindo apenas URLs que exibem o tempo limite (ou preferencialmente um URL de uma vez). Em um sistema típico, isso deve seguir uma distribuição normal ou de poisson - os pedidos que estão expirando podem ser simplesmente parte da cauda - nesse caso, você precisa concentrar seus esforços na sintonia geral. OTOH se a distribuição é bi-modal, então você precisa procurar por contenção em algum lugar no seu código.

    

Answer 2

Eu tenho outro pensamento sobre isso, com base no fato de que você recebe um grande número de solicitações por dia e parece ter tempo limite apenas durante o horário de pico (das fotos que você postou).

Há uma postagem no blog de falhas do servidor, Per Second Measurements Don't Cut It ... é possível que algumas dessas solicitações estejam correndo para o mesmo problema que a equipe do ServerFault encontrou?

We discovered that we were discarding packets pretty frequently on 1 Gbit/s interfaces at rates of only 10-30 MBit/s which hurts our performance. This is because that 10-30 MBit/s rate is really the number of bits transfered per 5 minutes converted to a one second rate. When we dug in closer with Wireshark and used one millisecond IO graphing, we saw we would frequently burst the 1 Mbit per millisecond rate of the so called 1 Gbit/s interfaces.