Problema de desempenho do Apache, após o “total de 1000 crianças”, o Apache não responde mais a solicitações HTTP. Não é problema de MaxClients?

Question

Esperando que alguém me aponte na direção certa, já que passei a semana passada tentando descobrir onde o "problema" está, mas não consegui, tentei postar nas listas de discussão dos usuários do Apache, mas queria saltar também aqui.

Executando o Apache 2.2.3 mod_php no CentOS 5.8.

Ao mesmo tempo, todos os dias, quando o tráfego está pesado, estamos tendo um problema em que o Apache não responde mais a solicitações HTTP.

Parecia que um problema padrão dos MaxClients estava sendo alcançado, mas esse não parece ser o caso.

Além disso, ao fazer login na máquina durante esse período, a média de carga é inferior a 1 e ainda há bastante RAM disponível.

Revendo / var / log / httpd / error_log Eu observei os seguintes padrões:

[Mon Apr 30 07:00:34 2012] [info] server seems busy, (you may need to increaseStartServers, or Min/MaxSpareServers), spawning 32 children, there are 0 idle, and 905 total children
[Mon Apr 30 07:00:35 2012] [info] server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers), spawning 32 children, there are 0 idle, and 937 total children
[Mon Apr 30 07:00:36 2012] [info] server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers), spawning 32 children, there are 0 idle, and 969 total children
[Mon Apr 30 07:00:37 2012] [info] server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers), spawning 32 children, there are 35 idle, and 1001 total children

[Mon Apr 30 07:00:42 2012] [debug] mpm_common.c(663): (70007)The timeout specified has expired: connect to listener on [::]:80 <br>
[Mon Apr 30 07:00:49 2012] [debug] mpm_common.c(663): (70007)The timeout specified has expired: connect to listener on [::]:80 <br>
[Mon Apr 30 07:00:56 2012] [debug] mpm_common.c(663): (70007)The timeout specified has expired: connect to listener on [::]:80 <br>
[Mon Apr 30 07:01:03 2012] [debug] mpm_common.c(663): (70007)The timeout specified has expired: connect to listener on [::]:80 <br>

Algumas vezes por dia, logo após o 1000 total children , o Apache para de responder e precisa ser reiniciado para funcionar novamente.

Revisei o error_log de algumas semanas atrás e é o mesmo padrão, o servidor atinge o total de 1.000 crianças e, em seguida, cospe imediatamente [debug] mpm_common.c(663): (70007)The timeout specified has expired: connect to listener on [::]:80 mensagem de erro e pára de responder.

No entanto, a carga no servidor é muito baixa ... Mesmo que eu tente e solicite um arquivo index.html simples, ele expirará.

Aqui está a seção relevante da configuração:

Timeout 45
KeepAlive On
MaxKeepAliveRequests 10000
KeepAliveTimeout 3

<IfModule prefork.c>
StartServers      80
MinSpareServers   50
MaxSpareServers  120
ServerLimit     3500
MaxClients      3500
MaxRequestsPerChild  2000
</IfModule>

Alguém sabe por que o número mágico de crianças que o Apache é capaz de alcançar é 1000 antes de parar de processar mais solicitações?

Ou como entender a mensagem (70007)The timeout specified has expired: connect to listener on [::]:80 ?

O "tempo limite especificado" refere-se a?

Eu verifiquei novamente o Max Open Files, que anteriormente estava em 1024, mas agora está em 16384, ainda é o mesmo problema.

    

Answer 1

É um tiro longo, mas eu tive problemas como este. Não me lembro exatamente qual mensagem de erro era, mas a razão para o problema sempre foi um programa PHP com bugs que criava solicitações recursivas (ou seja, o programa solicita uma URL que, por sua vez, solicita novamente a mesma URL, etc.). Eu vi isso, por exemplo, em conexão com ErrorDocument settings, em que o documento que deveria ter manipulado o erro era buggy ou inexistente e que acionou um erro.

Você pode facilmente verificar se esse pode ser o problema em seu access.log: você deve ter muitas solicitações do endereço IP do seu servidor, tudo em um tempo muito curto. Isso funciona até você atingir a configuração MaxClients ou até o sistema ficar sem recursos. A única correção é corrigir o programa PHP em questão.

    

Answer 2

Timeout 45 

Acredito que esteja se referindo a esse tempo limite. Pode ser que algo esteja abrindo a conexão, então não fazer nada (isto é, o cliente não está enviando nada depois de abrir a conexão ou talvez um script seu não esteja fechando a conexão depois de gravar dados no cliente) e o Apache aguarda 45 segundos antes de desistir. Em seguida, fecha a conexão. Você pode diminuir isso para que o Apache atinja as tentativas de conexão com o dud mais rápido, mas a melhor solução seria tentar determinar por que isso acontece em primeiro lugar.

link

Talvez também verifique esta página para problemas gerais de desempenho?

link

    

Answer 3

Verifique se o KeepAlive do Apache está ativado e qual é o valor de KeepAliveTimeout. Realmente não deve ser mais que 3 segundos. Ele manterá o processo / thread específico atribuído ao cliente durante esse período.

Em seguida, o comando conf do grep httpd para 1000 para ver se esse número está definido em algum lugar.

grep -r '1000' /etc/httpd/conf
grep -r '1000' /etc/httpd/conf.d

Além disso, pode ser um caso em que seu código php está (incorretamente) mantendo cada processo / thread que está lidando com ele indefinidamente e você está ficando sem eles.