it-swarm.com.de

Was bedeutet "AH00485: Anzeigetafel ist voll, nicht bei MaxRequestWorkers"?

Meine Umgebung

  • CentOS 6.4 X86_64
  • Apache 2.4.4
  • PHP 5.4.16 (FPM)
  • 2 Intel Xeon E5-2620 bei 2,00 GHz (8 Kerne, 16 Threads in jedem Prozessor)
  • 48 GB RAM registrierter Speicher.
  • 3 Festplatte 15 U/min 145 GB in RAID0 (von BIO

Interessante Variablen

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

Apache Server Status

Serverversion: Apache/2.2.4 (Unix) OpenSSL/1.0.1e mod_fastcgi/mod-fastcgi-SNAP-0910052141
Server erstellt: 24. Mai 2013, 16:48:07 Uhr


Aktuelle Zeit: Montag, 17. Juni 2013, 09:48:11 Uhr COT
Neustartzeit: Montag, 17. Juni 2013, 08:35:14 Uhr COT
Parent Server Config. Generation: 1
MPM-Generierung des übergeordneten Servers: 0
Server-Betriebszeit: 1 Stunde 12 Minuten 57 Sekunden
Serverlast: 0,05 0,10 0,09
Zugriffe insgesamt: 14144 - Gesamtverkehr: 349,7 MB
CPU-Auslastung: u.28 s.25 cu0 cs0 - .0121% CPU-Auslastung
3,23 Anfragen/Sek. - 81,8 kB/Sekunde - 25,3 kB/Anfrage
1 Anfragen werden derzeit bearbeitet, 191 untätige Mitarbeiter

  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

Fehlerprotokoll

Die Fehlermeldung lautet

[Mon Jun 17 09: 32: 45.680842 2013] [mpm_event: error] [pid 8574: tid 140185091581760] AH00485: Anzeigetafel ist voll, nicht bei MaxRequestWorkers

Dies erscheint alle paar Sekunden. Ich verstehe es nicht. Wie kann ich es reparieren?

27
Jose Nobile

Wir hatten das gleiche Problem mit Apache 2.4.6. Nachdem wir den Server überwacht und die Einstellung einige Stunden lang angepasst haben, scheint es uns, dass Apache einen Fehler hat. Was zu passieren scheint, ist, dass die Serverprozesse gelegentlich in den Status G wechseln (ordnungsgemäß beendet) und neu gestartet werden, um neue Anforderungen zu akzeptieren. Das ist normal. Was nicht normal ist, ist, dass der Neustart aus irgendeinem Grund bis zu einigen Minuten dauern kann. Wenn nur wenige Serverprozesse ausgeführt werden und alle gleichzeitig in den Status G wechseln, füllt sich Ihre Anzeigetafel und Sie können keine weiteren Anforderungen mehr bearbeiten.

Wir haben die Anzahl der Server erhöht, sodass die Wahrscheinlichkeit geringer ist, dass alle gleichzeitig in den Status G wechseln. Stellen Sie außerdem sicher, dass Sie jedem Serverprozess mindestens 25 Threads (MaxRequestWorkers) zuweisen, da dies der Standard zu sein scheint (dh wenn 5 Servers x 25 ThreadsPerChild = 125 MaxRequestWorkers). Sie können ThreadsPerChild ändern, wenn Sie möchten. Wir haben es auf der Standardeinstellung belassen. Wenn Sie nicht genügend Threads zuweisen, werden die zusätzlichen Server nicht gestartet. Wir haben MinSpareThreads auf dem Standardwert von 25 und dem Standardwert für MaxSpareThreads von 75 belassen. Wenn Sie diese Einstellungen ändern, muss der Wert für MaxSpareThreads größer als oder sein gleich der Summe von MinSpareThreads und ThreadsPerChild. Außerdem muss MaxRequestWorkers gleich oder kleiner als ServerLimit sein.

Hier ist, was für uns funktioniert hat, aber es ist möglicherweise nicht die beste Konfiguration für Sie.

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

Bearbeiten: Dies ist ein bestätigter Fehler im httppm-Modul mpm_event, der möglicherweise nicht durch Konfiguration behoben werden kann.
Der verknüpfte Eintrag Bugtracker enthält einen vermuteten Patch und weitere Diskussionen darüber, wie dies behoben werden kann, bis eine neue Version des Ereignismoduls offiziell veröffentlicht wird.

19
Kam

Das gleiche Problem sehen.

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 

Wir können dieses Verhalten insbesondere durch erneutes Laden von Apache verursachen.

Was wir dann sehen, sind ein paar alte Prozesse, die nicht aufhören:

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

Beachten Sie die "älteren" und "neueren" PIDs und Startzeiten. ^^

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

Wir haben dies festgestellt, als eine unserer Replikatdatenbanken offline ging und das Zeitlimit überschritten wurde. Dies hat eine Unmenge von Fäden in Apache zusammengebunden, anscheinend bis die Dinge ziemlich kaputt waren und wir diese Nachricht erhielten.

Wahrscheinlich nicht der Normalfall, aber ich sende dies der Canon in der Hoffnung, dass es anderen helfen kann, die diesen Fehler sehen.

0
mlissner