Что означает «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 145GB в 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 с.25 cu0 cs0 - .0121% ЦП загрузка
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: error] [pid 8574: tid 140185091581760] AH00485: табло заполнено, не в MaxRequestWorkers

Это появляется каждые несколько секунд. Я не понимаю это Как я могу это исправить?

apache-2.2 mpm-worker apache-2.4 Хосе Нобиле
источник

Ответы:

18

У нас была такая же проблема на Apache 2.4.6. После мониторинга сервера и изменения настроек в течение нескольких часов нам кажется, что в Apache может быть ошибка. Кажется, что происходит то, что серверные процессы время от времени переходят в Gсостояние (изящное завершение) и перезапускаются для принятия новых запросов, это нормально. Что не является нормальным, так это то, что по какой-то причине перезагрузка может занять до нескольких минут. Если у вас запущено только несколько серверных процессов, и все они одновременно переходят в Gсостояние, тогда ваше табло заполняется, и вы больше не сможете отправлять запросы.

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

Вот что сработало для нас, но, возможно, это не лучшая конфигурация для вас. 

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

Изменить: Это подтвержденная ошибка в модуле httpd mpm_event, которая может быть не исправлена в конфигурации.
Связанный багтрекер запись имеет предполагаемую заплатку и более подробное обсуждение о том , чтобы исправить это , пока новая версия модуля события официально выпущена.

Kam
источник
Ваша 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. По-видимому, он появился после перезагрузки, вызванной logrotate, и процессы продолжают записываться error.log.1. error.logтолько упоминает перезагрузку.
Жером
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

В частности, мы можем вызвать такое поведение, перезагрузив apache.

Затем мы видим пару старых процессов, которые не останавливаются:

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, по-видимому, до тех пор, пока что-то не сломалось, и мы не начали получать это сообщение.

Вероятно, это не обычный случай, но я передаю это канону в надежде, что это может помочь другим, которые увидят эту ошибку.

mlissner
источник