Що означає "AH00485: табло заповнене, а не в MaxRequestWorkers"?


25

Моє довкілля

  • CentOS 6.4 X86_64
  • Apache 2.4.4
  • PHP 5.4.16 (FPM)
  • 2 Intel Xeon E5-2620 при 2,00 ГГц (8 ядер, 16 потоків у кожному процесорі)
  • 48 ГБ оперативної пам'яті.
  • 3 жорсткий диск 15RPM 145 ГБ в RAID0 (від BIO

Цікаві змінні

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

Статус сервера Apache

Версія сервера: Apache / 2.2.4 (Unix) OpenSSL / 1.0.1e mod_fastcgi / mod-fastcgi-SNAP-0910052141
Побудований сервер: 24 травня 2013 16:48:07


Поточний час: понеділок, 17 червня 2013 09:48:11
Час перезавантаження COT : понеділок, 17 червня 2013 08:35:14
Конфігуруйте батьківський сервер COT . Генерація: 1
Батьківський сервер MPM Покоління: 0
Продовження часу на сервері: 1 година 12 хвилин 57 секунд
Навантаження сервера: 0,05 0,10 0,09
Загальний доступ: 14144 - Загальний трафік: 349,7 Мб
Використання процесора: u.28 s.25 cu0 cs0 - .0121% CPU завантаження
3,23 запиту / сек - 81,8 кБ / секунду - 25,3 кБ / запит
1 запит зараз обробляється, 191 непрацюючих працівників

  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

Журнал помилок

Повідомлення про помилку є

[Пн 17 червня 09: 32: 45.680842 2013] [mpm_event: помилка] [pid 8574: tid 140185091581760] AH00485: табло заповнене, не в MaxRequestWorkers

Це з’являється кожні кілька секунд. Я цього не розумію. Як я можу це виправити?

Відповіді:


18

У нас була така ж проблема з Apache 2.4.6. Після моніторингу сервера та коригування налаштувань протягом декількох годин нам здається, що в Apache може виникнути помилка. Здається, що серверні процеси періодично переходять у Gстан (витончено закінчується) і перезапускаються, щоб приймати нові запити, це нормально. Що не нормально, це те, що чомусь це може зайняти до декількох хвилин, щоб перезапустити. Якщо у вас лише кілька запущених серверів, і всі вони переходять у Gстан одночасно, тоді ваше табло заповнюється, і ви більше не зможете подавати сервер.

Те, що ми зробили, - збільшити кількість серверів, тому є менше шансів, що всі вони Gодночасно перейдуть у стан. Також переконайтеся, що ви виділили щонайменше 25 потоків ( MaxRequestWorkers) для кожного серверного процесу, оскільки це видається за замовчуванням (тобто, якщо 5 Serversx 25 ThreadsPerChild= 125 MaxRequestWorkers). Ви можете змінити, ThreadsPerChildякщо вам подобається, ми залишили його за замовчуванням. Якщо ви не виділите достатню кількість потоків, додаткові сервери не запускатимуться. Ми залишили MinSpareThreadsзначення за замовчуванням, яке становить 25, а за замовчуванням MaxSpareThreads- 75. Якщо ви зміните ці налаштування, значення для MaxSpareThreadsповинно бути більше або рівне сумі MinSpareThreadsі ThreadsPerChild. Також MaxRequestWorkersмає бути рівним або меншим, ніж ServerLimit.

Ось що для нас працювало, але це може бути не найкращою конфігурацією для вас.

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

Редагувати: Це підтверджена помилка в модулі mpm_event httpd, яка може бути неможливо виправити через конфігурацію.
Пов'язаний багтрекер запис має передбачувану латочку і більш докладне обговорення про те , щоб виправити це , поки нова версія модуля події офіційно випущена.


Ваша MaxConnectionsPerChildустановка занадто низька для виробництва. Крім того, встановити його на що-небудь, крім 0, потрібно робити лише в Windows, оскільки воно протікає всередині пам'яті.
rustyx

Apache error_log також дає підказки:MaxRequestWorkers of 40 is not an integer multiple of ThreadsPerChild of 25, decreasing to nearest multiple 25
dhaupin

1
MaxSpareServers / MinSpareServers не застосовуються до mpm_event. Я не впевнений, що ви тут мали на увазі, оскільки цифри занадто низькі, щоб бути MaxSpareThreads / MinSpareThreads.
Хаміш Моффтат

Також зіткнувся з цією проблемою на Debian при обертанні журналу Apache2. Зверніться до support.plesk.com/hc/en-us/articles/…
Ів Мартін

Патч, згаданий у цій відповіді, був об'єднаний у 2.4.25. Я тут, тому що у мене є проблема, хоча я використовую 2.4.25. Мабуть, він з’явився при перезавантаженні, викликаному логротатом, і процеси продовжують записувати error.log.1. error.logзгадує лише перезавантаження.
Jérôme

3

Побачивши ту саму проблему.

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 

Особливо ми можемо викликати таку поведінку, перезавантаживши апачі.

То, що ми бачимо, - це кілька старих процесів, які не припиняються:

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

Зауважте "старіші" та "новіші" PID та час початку. ^^

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

0

Ми почали бачити це, коли одна з наших реплік баз даних перейшла в режим офлайн і почала відмічатися. Це пов’язало газильйон ниток в Apache, мабуть, поки все не було зламано, і ми почали отримувати це повідомлення.

Можливо, це не звичайний випадок, але я подаю це до канону, сподіваючись, що це може допомогти іншим, хто бачить цю помилку.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.