web-dev-qa-db-fra.com

Quelle est la signification de "AH00485: le tableau de bord est plein, pas chez MaxRequestWorkers"?

Mon environnement

  • CentOS 6.4 X86_64
  • Apache 2.4.4
  • PHP 5.4.16 (FPM)
  • 2 Intel Xeon E5-2620 à 2,00 GHz (8 cœurs, 16 threads dans chaque processeur)
  • 48 Go RAM mémoire enregistrée.
  • 3 disques durs 15 tr/min 145 Go en RAID0 (par BIO

Variables intéressantes

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

État du serveur Apache

Version du serveur: Apache/2.2.4 (Unix) OpenSSL/1.0.1e mod_fastcgi/mod-fastcgi-SNAP-0910052141
Version du serveur: 24 mai 2013 16:48:07

Heure actuelle: lundi 17 juin 2013 09:48:11 COT
Heure de redémarrage: lundi 17 juin 2013 08:35:14 COT
Configuration du serveur parent. Génération: 1
Génération MPM du serveur parent: 0
Disponibilité du serveur: 1 heure 12 minutes 57 secondes
Charge du serveur: 0,05 0,10 0,09
Nombre total d'accès: 14144 - Trafic total: 349,7 Mo
Utilisation CPU: u.28 s.25 cu0 cs0 - .0121% charge CPU
3,23 requêtes/sec - 81,8 kB/seconde - 25,3 kB/requête
1 demandes en cours de traitement, 191 travailleurs inactifs

  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

Journal des erreurs

Le message d'erreur est

[Lun 17 juin 09: 32: 45.680842 2013] [mpm_event: erreur] [pid 8574: tid 140185091581760] AH00485: le tableau de bord est plein, pas chez MaxRequestWorkers

Cela apparaît toutes les quelques secondes. Je ne comprends pas. Comment puis-je le réparer?

apache-2.2mpm-workerapache-2.4
27
Jose Nobile

Nous avons eu le même problème sur Apache 2.4.6. Après avoir surveillé le serveur et ajusté le paramètre pendant plusieurs heures, il nous semble qu'Apache peut avoir un bug. Ce qui semble se produire, c'est que les processus du serveur passent parfois à l'état G (se terminant avec grâce) et redémarrent pour accepter de nouvelles demandes, c'est normal. Ce qui n'est pas normal, c'est que pour une raison quelconque, cela peut prendre jusqu'à quelques minutes pour redémarrer. Si vous n'avez que quelques processus serveur en cours d'exécution et qu'ils passent tous à l'état G en même temps, votre tableau de bord se remplit et vous ne pourrez plus traiter de demandes.

Ce que nous avons fait, c'est augmenter le nombre de serveurs afin qu'il y ait moins de chances qu'ils passent tous à l'état G en même temps. Assurez-vous également d'allouer au moins 25 threads (MaxRequestWorkers) pour chaque processus serveur car cela semble être la valeur par défaut (c'est-à-dire si 5 Servers x 25 ThreadsPerChild = 125 MaxRequestWorkers). Vous pouvez modifier ThreadsPerChild si vous le souhaitez, nous l'avons laissé par défaut. Si vous n'allouez pas suffisamment de threads, les serveurs supplémentaires ne démarreront pas. Nous avons laissé MinSpareThreads à la valeur par défaut qui est 25 et la valeur par défaut à MaxSpareThreads qui est 75. Si vous modifiez ces paramètres, la valeur de MaxSpareThreads doit être supérieure à ou égal à la somme de MinSpareThreads et ThreadsPerChild. MaxRequestWorkers doit également être inférieur ou égal à ServerLimit.

Voici ce qui a fonctionné pour nous, mais ce n'est peut-être pas la meilleure configuration pour vous.

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

Edit: Ceci est un bug confirmé dans le module mpm_event de httpd qui pourrait ne pas être réparable via la configuration.
L'entrée liée bugtracker a un correctif présumé et plus de discussion sur la façon de résoudre ce problème jusqu'à ce qu'une nouvelle version du module d'événement soit officiellement publiée.

19
Kam

Voyant le même problème.

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

Nous pouvons en particulier provoquer ce problème en rechargeant Apache.

Ce que nous voyons alors, ce sont quelques vieux processus qui ne s'arrêtent pas:

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

Notez les PID "anciens" et "plus récents" et les heures de début. ^^

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
3
Serge van Ginderachter

Nous avons commencé à voir cela lorsque l'une de nos bases de données de réplicas s'est déconnectée et a commencé à expirer. Cela a bloqué un million de fils dans Apache, apparemment jusqu'à ce que les choses soient plutôt cassées et que nous commencions à recevoir ce message.

Probablement pas le cas normal, mais je soumets cela au Canon dans l'espoir que cela puisse aider les autres qui voient cette erreur.

0
mlissner