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 a 15% e não apresenta 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 o código PHP é otimizado e rápido principalmente quando é acessado, porém às vezes as solicitações ficam travadas. Significado preso; nenhuma resposta por pelo menos 10 segundos. Depuramos o código PHP, mas é bastante otimizado e rápido. Passamos muito tempo nisso até que decidimos testar a solicitação de:
<html><body>test</body></html>
página test.html.
Este recurso estático também fica 'travado' da mesma maneira que as páginas php ficam 'travadas'.
Como isso é possível dada a saúde do sistema e o fato de ser um arquivo estático?
Testei a rede, mas, quando o PHP mostra 'lentidão' no monitoramento do site, os arquivos de teste html também demoram (bem mais) que 10 segundos para carregar usando;
time lynx -dump http://127.0.0.1/test.html
Estamos meio desesperados para resolver esse problema, mas parece que não conseguimos enfrentá-lo.
Responder1
Talvez o Apache fique sem identificadores de arquivo? Quantos identificadores de arquivo você permitiu? O padrão 1024 pode se tornar um gargalo em breve. No Linux você aumenta os limites do /etc/security/limits.confarquivo.
Há muita atividade no disco durante as paralisações? Se você tiver o log de acesso do Apache e outros logs ativados de maneira muito detalhada, talvez seja o sistema de arquivos que está confirmando as alterações mais recentes? Isso não deve afetar o Apache de forma alguma, mas nunca se sabe.
E só para ter certeza, dê uma olhada /proc/sys/kernel/random/entropy_availdurante as barracas. Você pode ver isso com, por exemplo watch -n1 'cat /proc/sys/kernel/random/entropy_avail'. Se disser 0, seu kernel ficou sem entropia e isso bloqueia o Apache até que haja mais entropia disponível.
Se for esse o caso, você pode instalar rng-toolse executar o rngddaemon, que transfere números semi-aleatórios de /dev/urandom para /dev/random nas situações em que a entropia real não está disponível.
Responder2
Eu não investiguei os detalhes internos, mas pela minha experiência e pelo que me disseram... se o PHP estiver rodando no Apache usando o módulo incorporado ( libphp5.so), então o Apache carrega o PHP (e opcionalmente, quaisquer módulos compartilhados) na memória em cada solicitação, mesmo que o código PHP não esteja sendo executado.
Considere usarnginxcomo um proxy reverso na frente do Apache. O nginx é incrivelmente rápido no atendimento de recursos estáticos e, se configurado corretamente, pode realmente reduzir a carga em um servidor web ocupado. Para ganhar pontos extras, configure o PHP para rodar via FastCGI no nginx. Dê uma olhadaEste artigopara descobrir alguns motivos. É realmente um ótimo caminho a seguir. Eu configurei um novo servidor web com Ubuntu 10.04, nginx, spawn-fcgi e php-cgi na semana passada e quase não demorou muito. O PHP 5.3 vem junto com o Ubuntu 10.04, para constar.