Qual è il significato di "AH00485: il tabellone segnapunti è pieno, non su MaxRequestWorkers"?

Il mio ambiente

• CentOS 6.4 X86_64
• Apache 2.4.4
• PHP 5.4.16 (FPM)
• 2 Intel Xeon E5-2620 a 2,00 GHz (8 core, 16 thread in ciascun processore)
• Memoria registrata da 48 GB di RAM.
• 3 Hard Disk 15 RPM 145GB in RAID0 (da BIO

Variabili interessanti

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

Stato del server Apache

Versione server: Apache / 2.2.4 (Unix) OpenSSL / 1.0.1e mod_fastcgi / mod-fastcgi-SNAP-0910052141
Server costruito: 24 maggio 2013 16:48:07

---

Ora corrente: lunedì 17-giu-2013 09:48:11
Orario di riavvio COT : lunedì 17-giu-2013 08:35:14
Config server padre COT . Generazione: 1
Server principale MPM Generazione: 0
Tempo di attività del server: 1 ora 12 minuti 57 secondi
Carico del server: 0,05 0,10 0,09
Accesso totale: 14144 - Traffico totale: 349,7 MB
Utilizzo CPU: u.28 s.25 cu0 cs0 - .0121% CPU carica
3,23 richieste / sec - 81,8 kB / secondo - 25,3 kB / richiesta
1 richieste attualmente in elaborazione, 191 lavoratori inattivi

  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

Registro errori

Il messaggio di errore è

[Lun 17 giugno 09: 32: 45.680842 2013] [mpm_event: errore] [pid 8574: tid 140185091581760] AH00485: il tabellone è pieno, non su MaxRequestWorkers

Questo appare ogni pochi secondi. Non lo capisco Come posso ripararlo?

Abbiamo avuto lo stesso problema su Apache 2.4.6. Dopo aver monitorato il server e aver modificato le impostazioni per diverse ore, ci sembra che Apache possa avere un bug. Ciò che sembra accadere è che i processi del server di tanto in tanto entrino nello Gstato (terminando con grazia) e si riavviino per accettare nuove richieste, è normale. Ciò che non è normale è che per qualche motivo questo può richiedere alcuni minuti per riavviarsi. Se hai solo pochi processi server in esecuzione e tutti vanno nello Gstato contemporaneamente, il tuo tabellone si riempie e non sarai in grado di soddisfare altre richieste.

Quello che abbiamo fatto è stato aumentare il numero di server, quindi c'è meno possibilità che entrino nello Gstato contemporaneamente. Assicurati anche di allocare almeno 25 thread ( MaxRequestWorkers) per ogni processo del server perché quello sembra essere il default (cioè se 5 Serversx 25 ThreadsPerChild= 125 MaxRequestWorkers). Puoi cambiare ThreadsPerChildse vuoi, l'abbiamo lasciato di default. Se non si allocano abbastanza thread, i server aggiuntivi non verranno avviati. Abbiamo lasciato MinSpareThreadsil valore predefinito che è 25 e il valore predefinito per MaxSpareThreadscui è 75. Se si modificano queste impostazioni, il valore per MaxSpareThreadsdeve essere maggiore o uguale alla somma di MinSpareThreadse ThreadsPerChild. Inoltre MaxRequestWorkersdeve essere uguale o inferiore a ServerLimit.

Ecco cosa ha funzionato per noi, ma potrebbe non essere la migliore configurazione per te.

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

Modifica: questo è un bug confermato nel modulo mpm_event di httpd che potrebbe non essere risolvibile tramite la configurazione.
La voce bugtracker collegata ha una presunta patch e ulteriori discussioni su come risolvere questo problema fino al rilascio ufficiale di una nuova versione del modulo eventi.

Vedendo lo stesso 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 

In particolare, possiamo causare questo comportamento ricaricando Apache.

Quello che poi vediamo, sono un paio di vecchi processi che non si fermano:

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

Notare i PID "più vecchi" e "più recenti" e gli orari di inizio. ^^

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

Abbiamo iniziato a vedere questo quando uno dei nostri database di replica è andato offline e ha iniziato il timeout. Ciò ha legato un gazillion di thread in Apache, apparentemente fino a quando le cose non sono state piuttosto rotte e abbiamo iniziato a ricevere questo messaggio.

Probabilmente non è il caso normale, ma lo sottopongo al canone nella speranza che possa aiutare gli altri a vedere questo errore.