Los trabajadores de Apache MPM atrapados en G (terminando con gracia) crecen: "el marcador está lleno"

Question

Ejecutando el trabajador MPM, Apache 2.4.46, Debian 9

Los trabajadores que terminan con gracia simplemente crecen con el tiempo, parece que nunca terminan. Al final me quedo sin capacidad y aparece el error "el marcador está lleno". Si reinicio Apache, se liberan.

No creo que tenga nada que ver con el código de mi sitio web (php), ya que muchas de las solicitudes colgantes son solo GET de imágenes puras, sin php involucrado.

<IfModule mpm_worker_module>
ServerLimit 500
StartServers       10
MinSpareThreads    50
MaxSpareThreads    100
    ThreadLimit          64
    ThreadsPerChild      64
    MaxRequestWorkers     500
    MaxConnectionsPerChild   0
</IfModule>

marcador

ejemplo g trabajadores

Apache durante la semana, los espacios libres están disminuyendo

probado con mantener vivo dentro y fuera

Answer 1

Cuando utiliza el trabajador MPM, las solicitudes son manejadas por subprocesos que existen en los procesos.

Dehttps://httpd.apache.org/docs/2.4/mod/worker.html

Un único proceso de control (el padre) es responsable de iniciar los procesos secundarios. Cada proceso hijo crea un número fijo de subprocesos de servidor como se especifica en la directiva ThreadsPerChild, así como un subproceso de escucha que escucha las conexiones y las pasa a un subproceso de servidor para procesarlas cuando llegan.

En Linux, un proceso 'contiene' subprocesos, es decir, un PID puede tener múltiples subprocesos que comparten memoria (entre otros recursos) con otros subprocesos en ese PID.

De hecho, a Linux realmente sólo le importan las "tareas", un proceso sin subprocesos múltiples es un PID con un contenedor deunotarea.

Cuando recargas Apache correctamente, estás finalizando el proceso que lo contiene. Lo que está sucediendo aquí es que Apache está haciendo que cada subproceso espere hasta que todos los subprocesos en el proceso contenedor se hayan completado antes de reiniciar el PID del contenedor.

Entonces, en su caso, tiene un único hilo contenido en todos los procesos en esa lista que todavía está ocupado o atascado de alguna manera.

Tienes algunas opciones.

1. Simplemente deja de esperar de todos modos y reinicia.
2. Encuentre el hilo del problema (podría ser un error en la aplicación) y corríjalo.

1, es fácil. Agregue la opción de configuración GracefulShutdownTimeoutcon un valor alto pero no estúpido. Digamos 900 segundos. De forma predeterminada, esto es infinito, lo que significa que sus hilos esperan una eternidad hasta que finalice el hilo problemático.

La principal desventaja de esto es que corres la posibilidad de acceder a un proceso mientras estás haciendo algo crítico, lo que a su vez podría dañar un archivo o romper la aplicación sutilmente. También tiene una posibilidad (muy pequeña) de cancelar a un cliente a mitad del procesamiento.

2, implicará que usted detecte el hilo que está atascado en la lista de trabajadores y luego diagnostique lo que está haciendo la conexión, pero seguramente encontrará lo que podría ser un defecto de diseño y podrá explicar el comportamiento con más confianza antes de simplemente arruinarlo. eliminar un hilo problemático.