Co oznacza „AH00485: tablica wyników jest pełna, a nie w MaxRequestWorkers”?

Moje środowisko

• CentOS 6.4 X86_64
• Apache 2.4.4
• PHP 5.4.16 (FPM)
• 2 procesory Intel Xeon E5-2620 @ 2,00 GHz (8 rdzeni, 16 wątków w każdym procesorze)
• 48 GB pamięci RAM.
• 3 dysk twardy 15 RPM 145 GB w RAID0 (BIO

Ciekawe zmienne

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

Status serwera Apache

Wersja serwera: Apache / 2.2.4 (Unix) OpenSSL / 1.0.1e mod_fastcgi / mod-fastcgi-SNAP-0910052141
Zbudowany serwer: 24 maja 2013 16:48:07

---

Aktualny czas: poniedziałek, 17 czerwca 2013 09:48:11 COT
Czas ponownego uruchomienia: poniedziałek, 17 czerwca 2013 08:35:14 COT
Konfiguracja serwera nadrzędnego. Generacja: 1
serwer nadrzędny Generacja MPM: 0 Czas działania
serwera: 1 godzina 12 minut 57 sekund
Obciążenie serwera: 0,05 0,10 0,09
Łączny dostęp: 14144 - Całkowity ruch: 349,7 MB
Wykorzystanie procesora: u.28 s.25 cu0 cs0 - .0121% CPU obciążenie
3,23 żądania / s - 81,8 kB / sekundę - 25,3 kB / żądanie
1 aktualnie przetwarzane wnioski, 191 wolnych pracowników

  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

Dziennik błędów

Komunikat o błędzie to

[Mon Jun 17 09: 32: 45.680842 2013] [mpm_event: error] [pid 8574: tid 140185091581760] AH00485: tablica wyników jest pełna, nie w MaxRequestWorkers

Pojawia się co kilka sekund. Nie rozumiem tego Jak mogę to naprawić?

Mieliśmy ten sam problem w Apache 2.4.6. Po kilku godzinach monitorowania serwera i zmianie ustawień wydaje nam się, że Apache może mieć błąd. Wydaje się, że zdarza się, że procesy serwera czasami przechodzą w Gstan (z gracją kończą) i restartują się, aby zaakceptować nowe żądania, co jest normalne. Co nie jest normalne, to z jakiegoś powodu ponowne uruchomienie może potrwać kilka minut. Jeśli masz uruchomionych tylko kilka procesów serwera i wszystkie one przejdą w Gstan w tym samym czasie, twoja tablica wyników zapełni się i nie będziesz w stanie przesyłać kolejnych żądań.

Zwiększyliśmy liczbę serwerów, więc istnieje mniejsze prawdopodobieństwo, że wszystkie wejdą w Gstan w tym samym czasie. Upewnij się również, że przydzielono przynajmniej 25 wątków ( MaxRequestWorkers) dla każdego procesu serwera, ponieważ wydaje się, że jest to ustawienie domyślne (tj. Jeśli 5 Serversx 25 ThreadsPerChild= 125 MaxRequestWorkers). Możesz zmienić, ThreadsPerChildjeśli chcesz, pozostawiliśmy to domyślnie. Jeśli nie przydzielisz wystarczającej liczby wątków, dodatkowe serwery się nie uruchomią. Zostawiliśmy MinSpareThreadsdomyślną wartość 25, a domyślną MaxSpareThreads75. Jeśli zmienisz te ustawienia, wartość dla MaxSpareThreadsmusi być większa lub równa sumie MinSpareThreadsi ThreadsPerChild. Również MaxRequestWorkersmusi być równy lub mniejszy niż ServerLimit.

Oto, co nam pomogło, ale może nie być to najlepsza konfiguracja dla Ciebie.

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

Edycja: Jest to potwierdzony błąd w module mpm_event httpd, który może nie zostać naprawiony przez konfigurację.
Link do wpisu bugtrackera zawiera przypuszczalną łatkę i więcej dyskusji na temat tego, jak to naprawić, dopóki nowa wersja modułu zdarzeń nie zostanie oficjalnie wydana.

Widzę ten sam problem.

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 

W szczególności możemy spowodować takie zachowanie, ponownie ładując apache.

Następnie widzimy kilka starych procesów, które się nie zatrzymują:

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

Zwróć uwagę na „starsze” i „nowsze” PID oraz czasy rozpoczęcia. ^^

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

Zaczęliśmy to zauważać, gdy jedna z naszych baz danych replik przeszła w tryb offline i zaczęła upływać limit czasu. To wiązało gazillionowe wątki w Apache, najwyraźniej dopóki sprawy się nie popsuły i zaczęliśmy otrzymywać tę wiadomość.

Prawdopodobnie nie jest to normalny przypadek, ale przesyłam to do kanonu w nadziei, że może to pomóc innym, którzy widzą ten błąd.