Apache2 lento servindo estático enquanto saudável

Question

Meu status do Apache é semelhante;

201 requests/sec - 98.8 kB/second - 504 B/request
85 requests currently being processed, 345 idle workers
_____CCW_C_____C__C__C_R____C_WC_________C__C____CW__C__CCC_____
__C____W______C___C___CW__C_C______C__W_C__C_____CCC____C______R
CC_C_______C___C____C______________C______C__C________________C_
___________________C______________________C_______C___C_____C___
CC____C__C___R_____C_C_CC__________C___C___________R____C_C_C___
______C______W_W__W___C____________________C__WCC__R__R_C_______
R__RC________________________C___R____W__C____..................
....................................................

A carga do servidor é em média 2 em uma máquina de 4 núcleos.

A utilização de IO é de 10-15% e não tem muitos saltos acima de 70%.

A máquina tem quase 4 GB livres e usa 0 swap.

O site na máquina é um site PHP. Todo código PHP é otimizado e rápido, principalmente quando é acessado, no entanto, às vezes, as solicitações ficam bloqueadas. Significado preso; sem resposta por pelo menos 10 seg. Nós depuramos o código PHP, mas é ótimo e rápido. Nós gastamos muito tempo nisso até que decidimos testar o pedido de:

<html><body>test</body></html>

página test.html.

Este recurso estático também fica 'preso' da mesma maneira que as páginas php ficam 'presas'.

Como isso é possível dada a saúde do sistema e o fato de ser um arquivo estático?

Eu testei a rede, mas, quando o PHP mostra 'lentidão' no monitoramento do site, os arquivos de teste html também levam (muito mais tempo) do que 10 segundos para carregar usando;

time lynx -dump http://127.0.0.1/test.html

Estamos um pouco desesperados para resolver este problema, mas não conseguimos enfrentá-lo.

    

Answer 1

Talvez o Apache fique sem identificadores de arquivo? Quantos identificadores de arquivo você permitiu? O padrão 1024 pode ser um gargalo em breve. No Linux, você aumenta os limites no arquivo /etc/security/limits.conf .

Há muita atividade de disco durante as barracas? Se você tiver o log de acesso do Apache e outros logs muito habilitados, talvez o sistema de arquivos esteja confirmando as alterações mais recentes? Isso não deve afetar o Apache de qualquer forma, mas você nunca sabe.

E só para ter certeza, dê uma olhada em /proc/sys/kernel/random/entropy_avail durante as barracas. Você pode vê-lo com por exemplo watch -n1 'cat /proc/sys/kernel/random/entropy_avail' . Se ele diz 0 , seu kernel ficou sem entropia e isso bloqueia o Apache até que haja mais entropia disponível.

Se este for o caso, você pode instalar o rng-tools e executar o daemon rngd , que empilha números semi-aleatórios de / dev / urandom para / dev / random nas situações em que a entropia real não está disponível.

    

Answer 2

Eu não pesquisei os internos, mas pela minha experiência e pelo que me disseram ... se o PHP está rodando no Apache usando o módulo embutido ( libphp5.so ) então o Apache carrega o PHP (e opcionalmente, qualquer módulos compartilhados) na memória em todas as solicitações, mesmo se o código PHP não estiver sendo executado.

Considere o uso de nginx como um proxy reverso na frente do Apache. O nginx é incrivelmente rápido em servir recursos estáticos e, se configurado corretamente, pode realmente reduzir a carga em um servidor web ocupado. Para pontos de bônus, configure o PHP para rodar via FastCGI dentro do nginx. Dê uma olhada no artigo para descobrir algumas razões. É realmente um ótimo caminho a percorrer. Eu configurei um novo servidor web com o Ubuntu 10.04, nginx, spawn-fcgi e php-cgi na semana passada e não demorei muito tempo. O PHP 5.3 é fornecido com o Ubuntu 10.04, para o registro.