Apache2 PHP Site - Atingir o limite de MaxClients - diagnosticar?

Question

Temos um site de tráfego moderado (aproximadamente 20.000 acessos por dia), executando um aplicativo PHP / MySQL no Apache 2.2, Ubuntu 9.10 Server, a partir de uma instância do Amazon EC2 c1.small (1.7 Gb de RAM).

Tivemos problemas com o site repetidamente não respondendo. Como um hack sujo, eu configurei o MaxClients / ServerLimit para 450.

<IfModule mpm_prefork_module>
KeepAlive           On
KeepAliveTimeout     7
StartServers          5
MinSpareServers       5
MaxSpareServers      10
MaxClients          450
ServerLimit         450
MaxRequestsPerChild   0
</IfModule>

O site parece passar mais tempo do que antes, mas ainda morre. Verificando a lista de processos, eu tenho (terceira coluna é mem física, quarta coluna é tamanho virtual):

xxxxxxxxx@domU-XXXXXXXXX:/etc/apache2$ ps -eo pid,user,rss,vsz,args | grep apache
 2333 root     11092  39084 /usr/sbin/apache2 -k start
 3704 www-data 11060  41292 /usr/sbin/apache2 -k start
 3826 www-data 10016  39844 /usr/sbin/apache2 -k start
 3954 www-data 11976  41612 /usr/sbin/apache2 -k start
 4061 www-data 11844  41668 /usr/sbin/apache2 -k start
 4064 www-data 10988  40676 /usr/sbin/apache2 -k start
 4084 www-data 11804  41428 /usr/sbin/apache2 -k start
 4086 www-data 10192  39828 /usr/sbin/apache2 -k start
 4099 www-data 11876  41748 /usr/sbin/apache2 -k start
 4100 www-data 10980  40668 /usr/sbin/apache2 -k start
 4102 www-data  8952  39724 /usr/sbin/apache2 -k start
 4107 www-data 11856  41860 /usr/sbin/apache2 -k start
 4108 www-data  9952  39604 /usr/sbin/apache2 -k start
 4109 www-data     0      0 [apache2] <defunct>
 4114 www-data  7172  39724 /usr/sbin/apache2 -k start
 4115 www-data 10968  40668 /usr/sbin/apache2 -k start
 4122 www-data 11888  41844 /usr/sbin/apache2 -k start
 4123 www-data 11584  41444 /usr/sbin/apache2 -k start
 4124 www-data  7036  39596 /usr/sbin/apache2 -k start
 4125 www-data  6744  39084 /usr/sbin/apache2 -k start
 4126 www-data  9532  39552 /usr/sbin/apache2 -k start
 4127 www-data 10112  39812 /usr/sbin/apache2 -k start
 4128 www-data  6600  39084 /usr/sbin/apache2 -k start
 4129 www-data  6736  39084 /usr/sbin/apache2 -k start
 4130 www-data  7004  39596 /usr/sbin/apache2 -k start
 4131 www-data  6740  39084 /usr/sbin/apache2 -k start
 4132 www-data 11616  41596 /usr/sbin/apache2 -k start
 4134 www-data  7024  39588 /usr/sbin/apache2 -k start
 4135 www-data 11808  41516 /usr/sbin/apache2 -k start
 4136 www-data  7008  39460 /usr/sbin/apache2 -k start
 4137 www-data  6988  39460 /usr/sbin/apache2 -k start
 4139 1003       796   3040 grep --color=auto apache
victorhooi@domU-12-31-39-02-B6-34:/etc/apache2$

Existe uma maneira fácil de descobrir exatamente o que está acontecendo? Meu entendimento das entranhas do Apache não é tão bom, mas eu teria pensado que não precisaria de tantos processos simultâneos para servir uma página como essa, com esse tipo de tráfego. Nós herdamos o aplicativo, por isso não sabemos muito sobre o seu interior, mas é um site do tipo CMS bastante básico, mostrando alguns resultados de pesquisa, eu não acho que precisaria desse tipo de grunhido.

Eu corri ab contra o site, estava recebendo uma taxa de pedidos bastante ruim (bem abaixo de 50 por segundo), mas essa pode ter sido minha má escolha de configurações - muitas dessas solicitações pareciam falhar.

Onde devo procurar informações sobre o que está acontecendo ou alguma dica de solução de problemas que eu possa tentar?

Felicidades, Victor

    

Answer 1

450 crianças com um RSS de cerca de 10mb cada um tem mais de 4GB de uso de memória em potencial. Mais do que suficiente para fazer com que sua instância c1.small troque. A troca é quase sempre uma espiral descendente para os servidores apache.

Eu diria que as próximas coisas que eu gostaria de verificar são:  - o log de erro do apache faz menção a maxclients
 - dmesg ou / var / log / messages mencionam OOM killer em todos os  - é o servidor trocando
 - é o crescimento do uso de memória lento e estável ou pontudo / rápido de início

Os dois primeiros estão apenas olhando para arquivos txt. O terceiro você pode fazer cli mas gráficos ajudará, e o quarto você precisa de gráficos. Configure o mod_status do apache (provavelmente já existe um comentário) e aponte munin / collectd / cacti para ele.

Se você confirmar a causa é o esgotamento da memória e a troca, há toneladas que você pode fazer a partir daí. Primeiro, você pode diminuir seus maxclients para cerca de 150. Isso deixará algum espaço para outras coisas e para o cache do sistema de arquivos (o mysql aqui? Se for o caso, deixe mais). RSS é uma métrica grosseira para extrapolar assim é tudo o que temos. Depois de afinar, observe os gráficos ao longo do tempo e veja se você tem espaço para subir ou descer. De lá você pode se concentrar em 1.) crianças apache mais skinner (menos módulos, aperte a configuração do PHP) 2.) fazer o apache fazer menos (mistura de cdn, servidores http alternativos e opções de proxy http) 3.) upgrayyed

    

Answer 2

Você pode ter conexões persistentes abertas em seu servidor com um longo tempo limite. À medida que clientes adicionais continuam se conectando, eles ocupam cada vez mais os processos do apache. Com conexões persistentes, cada cliente pode ter 1 (ou mais) conexões com seu servidor.

Verifique isso para mais informações: link

    

Answer 3

Eu consolidei várias dicas de ajuste de desempenho no link para trabalhar recentemente; funcionou muito bem para as máquinas que eu apliquei recentemente. Além disso, se é um problema mais amplo de desempenho da máquina que pode não ser específico do Apache, eu tenho um artigo muito mais aprofundado em link que abrange a identificação de qual componente do sistema está causando problemas.

    

Answer 4

Você também pode tentar dizer ao Apache para iniciar com 50 processos (StartServers 50) para que ele não precise passar por toda a rotina de expansão do servidor quando for iniciado, tente aumentar seus servidores de reserva Max para cerca de 20 também para que os tópicos não desapareçam se seus pedidos vierem em ondas.