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

Question

Meu ambiente

• CentOS 6.4 X86_64
• Apache 2.4.4
• PHP 5.4.16 (FPM)
• 2 Intel Xeon E5-2620 @ 2.00GHz (8 núcleos, 16 threads em cada processador)
• Memória registrada RAM de 48 GB.
• 3 Disco Rígido de 15 RPM 145 GB em RAID0 (por 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

Server Version: Apache/2.2.4 (Unix) OpenSSL/1.0.1e mod_fastcgi/mod-fastcgi-SNAP-0910052141
Server Built: May 24 2013 16:48:07

---

Current Time: Monday, 17-Jun-2013 09:48:11 COT
Restart Time: Monday, 17-Jun-2013 08:35:14 COT
Parent Server Config. Generation: 1
Parent Server MPM Generation: 0
Server uptime: 1 hour 12 minutes 57 seconds
Server load: 0.05 0.10 0.09
Total accesses: 14144 - Total Traffic: 349.7 MB
CPU Usage: u.28 s.25 cu0 cs0 - .0121% CPU load
3.23 requests/sec - 81.8 kB/second - 25.3 kB/request
1 requests currently being processed, 191 idle workers

  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 é

[Mon Jun 17 09:32:45.680842 2013] [mpm_event:error] [pid 8574:tid 140185091581760] AH00485: scoreboard is full, not at MaxRequestWorkers

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

    

Answer 1

Tivemos o mesmo problema no Apache 2.4.6. Depois de 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 ocasionalmente entram no estado G (acabamento gracioso) e reinicia para aceitar novas solicitações, o que é normal. O que não é normal é que, por algum motivo, isso pode levar alguns minutos para ser reiniciado. Se você tiver apenas alguns processos do servidor em execução e todos entrarem no estado G ao mesmo tempo, seu painel de pontuação será preenchido e você não poderá mais solicitações do servidor.

O que fizemos foi aumentar o número de servidores para que houvesse uma menor chance de todos entrarem no estado G ao mesmo tempo. Além disso, certifique-se de alocar pelo menos 25 encadeamentos ( MaxRequestWorkers ) para cada processo do servidor, porque esse parece ser o padrão (por exemplo, se 5 Servers x 25 ThreadsPerChild = 125 MaxRequestWorkers ). Você pode alterar ThreadsPerChild se quiser, deixamos como padrão. Se você não alocar threads suficientes, os servidores adicionais não serão iniciados. Deixamos MinSpareThreads com o valor padrão 25 e o padrão para MaxSpareThreads que é 75. Se você modificar essas configurações, o valor para MaxSpareThreads deverá ser maior ou igual à soma de MinSpareThreads e %código%. Também ThreadsPerChild deve ser igual ou menor que o MaxRequestWorkers .

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

Editar: Este é um bug confirmado no módulo mpm_event do httpd, que talvez não possa ser corrigido por meio de configuração.
A entrada bugtracker vinculada tem um patch presumido e mais discussões sobre como corrigir isso até uma nova versão do módulo do evento é lançado oficialmente.

    

Answer 2

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 

Nós particularmente 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 PIDs e horários de início "mais antigos" e "mais recentes". ^^

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

    

Answer 3

Começamos a ver isso quando um de nossos bancos de dados de réplica ficou off-line e começou o tempo limite. Isso amarrou um gazillion threads 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 submeto isso ao cânon na esperança de que isso possa ajudar outras pessoas que vêem esse erro.