Qual é o significado de "AH00485: o placar está cheio, não no MaxRequestWorkers"?

Meu ambiente

• CentOS 6.4 X86_64
• Apache 2.4.4
• PHP 5.4.16 (FPM)
• 2 Intel Xeon E5-2620 a 2.00GHz (8 núcleos, 16 threads em cada processador)
• Memória registrada de 48 GB de RAM.
• 3 Disco rígido 15RPM 145GB em RAID0 (da BIO

Variáveis ​​Interessantes

    <IfModule mpm_event_module>
        StartServers             2
        ThreadLimit             196
        MinSpareThreads         96
        MaxSpareThreads        192
        ThreadsPerChild         96
        MaxRequestWorkers      192
        MaxConnectionsPerChild   96
    </IfModule>

Status do servidor Apache

Versão do servidor: Apache / 2.2.4 (Unix) OpenSSL / 1.0.1e mod_fastcgi / mod-fastcgi-SNAP-0910052141
Servidor criado : 24 de maio de 2013 16:48:07

---

Hora atual: segunda-feira, 17 de junho de 2013 09:48:11
Hora de reinicialização do COT : segunda-feira, 17 de junho de 2013 08:35:14
Configuração do servidor pai do COT . Geração: 1
Servidor pai Geração MPM: 0 Tempo de
atividade do servidor: 1 hora 12 minutos 57 segundos
Carga do servidor: 0,05 0,10 0,09
Total de acessos: 14144 - Tráfego total: 349,7 MB
Uso da CPU: u.28 s.25 cu0 cs0 - .0121% CPU carregar
3,23 solicitações / s - 81,8 kB / segundo - 25,3 kB / solicitação
1 solicitações em processamento no momento, 191 trabalhadores ociosos

  PID | Connections       | Threads     | Async connections
      | total | accepting | busy | idle | keep-alive | closing
  ==============================================================
18997 | 3     | yes       | 1    | 95   | 0          | 3
18485 | 0     | yes       | 0    | 96   | 0          | 0
  ==============================================================
Sum   | 3     |           | 1    | 191  | 0          | 3

Log de erros

A mensagem de erro é

[17 de junho de 09: 32: 45.680842 2013] [mpm_event: error] [pid 8574: tid 140185091581760] AH00485: o placar está cheio, não no MaxRequestWorkers

Isso aparece a cada poucos segundos. Eu não entendo isso Como posso corrigir isso?

Tivemos o mesmo problema no Apache 2.4.6. Após monitorar o servidor e ajustar a configuração por várias horas, parece-nos que o Apache pode ter um bug. O que parece acontecer é que os processos do servidor entram ocasionalmente no Gestado (finalizando graciosamente) e são reiniciados para aceitar novas solicitações, isso é normal. O que não é normal é que, por algum motivo, isso pode levar alguns minutos para reiniciar. Se você tiver apenas alguns processos de servidor em execução e todos eles entrarem no Gestado ao mesmo tempo, seu placar será preenchido e você não poderá mais receber pedidos.

O que fizemos foi aumentar o número de servidores, para que haja menos chances de que todos eles entrem no Gestado ao mesmo tempo. Além disso, aloque pelo menos 25 threads ( MaxRequestWorkers) para cada processo do servidor, porque esse parece ser o padrão (por exemplo, se 5 Serversx 25 ThreadsPerChild= 125 MaxRequestWorkers). Você pode alterar, ThreadsPerChildse quiser, deixamos no padrão. Se você não alocar threads suficientes, os servidores adicionais não serão iniciados. Deixamos MinSpareThreadso valor padrão 25 e o padrão MaxSpareThreads75. Se você modificar essas configurações, o valor de MaxSpareThreadsdeve ser maior ou igual à soma de MinSpareThreadse ThreadsPerChild. Também MaxRequestWorkersdeve ser igual ou menor que o ServerLimit.

Aqui está o que funcionou para nós, mas pode não ser a melhor configuração para você.

StartServers 3
MinSpareServers 5
MaxSpareServers 10
ServerLimit 250
MaxRequestWorkers 250
MaxConnectionsPerChild 1000
KeepAlive Off

Edit: Este é um bug confirmado no módulo mpm_event do httpd que pode não ser corrigível através da configuração.
A entrada do bugtracker vinculado possui um patch presumido e mais discussões sobre como corrigir isso até que uma nova versão do módulo de evento seja oficialmente lançada.

Vendo o mesmo problema.

Apache 2.4.7-1ubuntu4.4 on Ubuntu 14.04
Server Version: Apache/2.4.7 (Ubuntu)
Server MPM: event
Server Built: Mar 10 2015 13:05:59 

Em particular, podemos causar esse comportamento recarregando o apache.

O que vemos então são alguns processos antigos que não param:

root     28192  0.0  0.8 103772  8648 ?        Ss   Mar16   0:03 /usr/sbin/apache2 -k start
www-data  2530  0.3  2.1 865188 21516 ?        Sl   06:26   0:54  \_ /usr/sbin/apache2 -k start
www-data  2531  0.2  2.1 865436 21892 ?        Sl   06:26   0:51  \_ /usr/sbin/apache2 -k start
www-data  3299  0.3  2.0 864140 20628 ?        Sl   06:46   0:51  \_ /usr/sbin/apache2 -k start
www-data  7305  0.3  2.1 865100 21504 ?        Sl   08:36   0:37  \_ /usr/sbin/apache2 -k start
www-data 11952  0.2  1.8 863004 19268 ?        Sl   10:46   0:06  \_ /usr/sbin/apache2 -k start
www-data 13284  0.0  0.6 103772  6692 ?        S    11:18   0:00  \_ /usr/sbin/apache2 -k start
www-data 13553  2.1  2.0 866156 21248 ?        Sl   11:23   0:01  \_ /usr/sbin/apache2 -k start

Observe os PID 'mais antigos' e os 'mais novos' e os horários de início. ^^

PID Connections     Threads Async connections
total   accepting   busy    idle    writing keep-alive  closing
7305    14  no  0   0   0   0   0
2530    13  no  0   0   0   0   0
3299    7   no  0   0   0   0   0
13553   65  no  17  8   0   25  25
2531    15  no  0   0   0   0   0
11952   10  no  0   0   0   0   0
Sum 124     17  8   0   25  25

GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
GGGGGGGGGGGW_WWWW__W_W_W_WWWWWWW__WWGGGGGGGGGGGGGGGGGGGGGGGGGGGG
GGGGGGGGGGGGGGGGGGGGGG

Começamos a ver isso quando um de nossos bancos de dados de réplicas ficou offline e começou a atingir o tempo limite. Isso amarrou um zilhão de tópicos no Apache, aparentemente até que as coisas estavam um pouco quebradas e começamos a receber essa mensagem.

Provavelmente não é o caso normal, mas apresento isso ao cânon na esperança de que ele ajude outras pessoas que veem esse erro.