¿Cuál es el significado de "AH00485: el marcador está lleno, no en MaxRequestWorkers"?


25

Mi entorno

  • CentOS 6.4 X86_64
  • Apache 2.4.4
  • PHP 5.4.16 (FPM)
  • 2 Intel Xeon E5-2620 @ 2.00GHz (8 núcleos, 16 hilos en cada procesador)
  • 48 GB de memoria RAM registrada.
  • 3 Disco duro 15RPM 145GB en RAID0 (por BIO

Variables interesantes

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

Estado del servidor Apache

Versión del servidor: Apache / 2.2.4 (Unix) OpenSSL / 1.0.1e mod_fastcgi / mod-fastcgi-SNAP-0910052141
Servidor construido: 24 de mayo de 2013 16:48:07


Hora actual: lunes 17 de junio de 2013 09:48:11 COT
Hora de reinicio: lunes 17 de junio de 2013 08:35:14
Configuración del servidor principal COT . Generación: 1
Servidor primario MPM Generación: 0
Tiempo de actividad del servidor: 1 hora 12 minutos 57 segundos
Carga del servidor: 0.05 0.10 0.09
Accesos totales: 14144 - Tráfico total: 349.7 MB
Uso de CPU: u.28 s.25 cu0 cs0 - .0121% CPU carga
3.23 solicitudes / seg. - 81.8 kB / segundo - 25.3 kB / solicitud
1 solicitudes actualmente en proceso, 191 trabajadores inactivos

  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

Registro de errores

El mensaje de error es

[Lun Jun 17 09: 32: 45.680842 2013] [mpm_event: error] [pid 8574: tid 140185091581760] AH00485: el marcador está lleno, no en MaxRequestWorkers

Esto aparece cada pocos segundos. No lo entiendo ¿Cómo puedo arreglarlo?

Respuestas:


18

Tuvimos el mismo problema en Apache 2.4.6. Después de monitorear el servidor y ajustar la configuración durante varias horas, nos parece que Apache puede tener un error. Lo que parece suceder es que los procesos del servidor ocasionalmente pasan al Gestado (finalizando con gracia) y se reinician para aceptar nuevas solicitudes, eso es normal. Lo que no es normal es que, por algún motivo, esto puede tardar unos minutos en reiniciarse. Si solo tiene unos pocos procesos de servidor en ejecución y todos entran en el Gestado al mismo tiempo, su marcador se llena y no podrá enviar más solicitudes.

Lo que hicimos fue aumentar el número de servidores, por lo que hay menos posibilidades de que todos ingresen al Gestado al mismo tiempo. También asegúrese de asignar al menos 25 subprocesos ( MaxRequestWorkers) para cada proceso del servidor porque parece ser el predeterminado (es decir, si 5 Serversx 25 ThreadsPerChild= 125 MaxRequestWorkers). Puede cambiar ThreadsPerChildsi lo desea, lo dejamos por defecto. Si no asigna suficientes subprocesos, los servidores adicionales no se iniciarán. Dejamos MinSpareThreadsel valor predeterminado que es 25 y el predeterminado para MaxSpareThreads75. Si modifica estas configuraciones, el valor de MaxSpareThreadsdebe ser mayor o igual que la suma de MinSpareThreadsy ThreadsPerChild. También MaxRequestWorkersdebe ser igual o menor que el ServerLimit.

Esto es lo que funcionó para nosotros, pero podría no ser la mejor configuración para usted.

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

Editar: Este es un error confirmado en el módulo mpm_event de httpd que podría no ser reparable a través de la configuración.
La entrada vinculada del bugtracker tiene un parche presunto y más discusión sobre cómo solucionar esto hasta que se publique oficialmente una nueva versión del módulo de eventos.


Su MaxConnectionsPerChildconfiguración es demasiado baja para su uso en producción. Además, establecerlo en algo que no sea 0 solo debe realizarse en Windows porque pierde memoria internamente.
rustyx

Apache error_log también da pistas:MaxRequestWorkers of 40 is not an integer multiple of ThreadsPerChild of 25, decreasing to nearest multiple 25
dhaupin

1
MaxSpareServers / MinSpareServers no son aplicables a mpm_event. No estoy seguro de lo que quisiste decir aquí porque los números son demasiado bajos para ser MaxSpareThreads / MinSpareThreads.
Hamish Moffatt

También enfrentó este problema en Debian en la rotación de registros de Apache2. Consulte support.plesk.com/hc/en-us/articles/…
Yves Martin

El parche mencionado en esta respuesta se fusionó en 2.4.25. Estoy aquí porque tengo el problema, aunque estoy usando 2.4.25. Aparentemente, apareció en una recarga activada por logrotate y los procesos continúan escribiendo error.log.1. error.logsolo menciona la recarga.
Jérôme

3

Al ver el mismo problema.

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 

Particularmente podemos causar este comportamiento recargando apache.

Lo que luego vemos son un par de procesos antiguos que no se detienen:

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

Observe los PID 'más antiguos' y 'más nuevos' y las horas de inicio. ^^

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

Comenzamos a ver esto cuando una de nuestras bases de datos de réplica se desconectó y comenzó a agotar el tiempo de espera. Esto ató un millón de hilos en Apache, aparentemente hasta que las cosas se rompieron y comenzamos a recibir este mensaje.

Probablemente no sea el caso normal, pero presento esto al canon con la esperanza de que pueda ayudar a otros que vean este error.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.