o apache é encerrado porque os MaxClients atingiram

3

tem um problema sério. Eu tenho servidor virtual que executa o Apache e dois projetos web com muitos visitantes (cerca de 5 acessos por segundo). Meu servidor começa a desligar sozinho. No log de erro, encontrei este problema

[error] server reached MaxClients setting, consider raising the MaxClients setting
[notice] caught SIGTERM, shutting down

então eu pesquiso solução para aumentar esses números. Eu descubro que esse número está em duas seções na confinguração do apache. Com

/usr/sbin/httpd -l
Compiled in modules:
  core.c
  prefork.c
  http_core.c
  mod_so.c

Descobri que meu servidor está usando o prefork. Então, eu novamente pesquisei valores apropriados e tentei fazer isso

<IfModule prefork.c>
    StartServers       8
    MinSpareServers    5
    MaxSpareServers   20
    ServerLimit     1024
    MaxClients      1024
    MaxRequestsPerChild  4000
</IfModule>

mas o servidor ainda é encerrado mesmo com esses valores. Alguém pode me guiar onde procurar, o que ler ou o que definir para uma execução estável adequada do servidor? Eu apreciarei qualquer ajuda, pessoal.

O servidor roda o Linux CentOS 5.4

Thx beny

    
por beny 09.02.2010 / 16:04

3 respostas

1

Como seu servidor está executando o modo prefork, isso significa que cada conexão obtém seu próprio processo - portanto, primeiro, verifique se existem 1024 processos httpd em execução no sistema.

Para entender melhor o que seu servidor está fazendo, talvez você queira ativar a página de status do servidor.

LoadModule status_module modules/mod_status.so

ExtendedStatus On

<Location /server-status>
    SetHandler server-status
    Order deny,allow
    Deny from all
    Allow from .example.com
</Location>

Isso permitirá que você visualize o estado das conexões com seu servidor e tente descobrir exatamente o que está causando o consumo de todas as conexões.

Minha suspeita é a possibilidade de algum tipo de proxy ou instrução reescrita que esteja fazendo com que o servidor continuamente conecte suas conexões dentro de si até que todas elas sejam consumidas.

    
por 09.02.2010 / 16:19
0

Talvez o seu servidor tenha ativado o recurso KeepAlive e um valor insanamente alto para KeepAliveTimeOut?

Isso pode gerar um monte de conexões inativas que esperam muito tempo para serem encerradas, terminando em uma falha de servidor.

Verifique na configuração do seu apache e / ou nas definições do virtualhost.

M

    
por 09.02.2010 / 17:02
0

Antes de aumentar o número novamente, você pode fazer algumas coisas para diminuir a quantidade de processos que o Apache gera.

Habilite o keepalive e defina um tempo limite baixo agressivo para ele:

KeepAlive On
MaxKeepAliveRequests 200
KeepAliveTimeout 5

Todas as solicitações do mesmo cliente serão tratadas por meio de uma única conexão TCP com o servidor. O valor baixo de KeepAliveTimeout significa que o Apache eliminará rapidamente a conexão KeepAlive, de modo que, desde que o cliente não deixe uma pausa de comunicação além de 5 segundos, o cliente poderá fazer uso de apenas uma conexão para todo o carregamento da página.

Além disso, diminua suas solicitações máximas por filho para algo como 1000. Os processos do Apache geralmente aumentam o uso de memória com cada solicitação, portanto, reduzir as solicitações máximas reduzirá o uso geral de memória para uma determinada quantidade de processos httpd.

Por último, como foi dito anteriormente, você deve observar o servidor durante a hora mais movimentada usando TOP ou o comando ps. Descubra quantos processos do apache estão sendo gerados e quanta memória cada um está consumindo. Em seguida, você pode calcular os clientes máximos apropriados com base nos servidores disponíveis e no uso de memória do processo.

Se você continuar a ver os problemas após esses ajustes, talvez seja melhor deixar de usar o módulo de pré-requisitos padrão do Apache e usar o módulo mpm de trabalho. Isso exigirá o uso de fastcgi ou algo semelhante para lidar com solicitações php; em última análise, embora isso seja uma boa idéia por si só.

tosse nginx tosse ;)

    
por 10.02.2010 / 00:12