Apache llegando a MaxClients y bloqueando el servidor


9

Actualmente tengo un servidor Apache2 que se ejecuta con mpm-preforky mod_phpen un VPS OpenVZ con 512M de RAM real / 1024M (sin intercambio). Después de ejecutar algunas pruebas, descubrí que el tamaño máximo de proceso que Apache obtiene es de 23M, así que lo configuré MaxClientsen 25 (23M x 25 = 575 MB, está bien para mí). Decidí ejecutar algunas pruebas de carga en mi servidor, y los resultados me dejaron perplejo.

Estoy usando aben mi máquina de escritorio solicitando la página principal de un blog de WordPress.

Cuando corro abcon 24 conexiones concurrentes, todo parece estar bien. Claro, la CPU sube, la RAM libre baja y el resultado es un tiempo de respuesta de 2-3 segundos por solicitud.

Pero si ejecuto abcon 25 conexiones concurrentes (el límite de mi servidor), Apache simplemente se cuelga después de un par de segundos. Comienza a procesar las solicitudes, luego deja de responder, la CPU vuelve al 100% de inactividad y abagota el tiempo de espera. El registro de Apache dice que llegó MaxClients.

Cuando esto sucede, Apache se mantiene encerrado con 25 procesos en ejecución (todos están en "W" si verifico el estado del servidor) y solo después de la TimeOutconfiguración, los procesos comienzan a morir y el servidor comienza a responder nuevamente (en mi caso, está configurado a 45).

Mi pregunta: ¿es ese comportamiento esperado? ¿Por qué Apache simplemente muere cuando llega MaxClients? Si funciona con 24 conexiones, ¿no debería funcionar con 25, simplemente tomando más tiempo para responder cada solicitud y haciendo cola con el resto?

Me parece un poco extraño que cualquier niño corriendo absolo pueda matar un servidor web simplemente configurando las conexiones concurrentes a los servidores MaxClients.

Respuestas:


17

¡DECIR AH! Finalmente encontré el problema yo mismo. Está más relacionado con la programación que con el administrador del servidor, pero decidí poner la respuesta aquí de todos modos porque al buscar en Google descubrí que no soy el único con ese tipo de problema (y como Apache se cuelga, la primera suposición es que hay un problema con el servidor)

El problema no es con Apache, sino con mi Wordpress. Más específicamente con mi tema. Estoy usando un tema llamado Lightworld y admite agregar una imagen al encabezado del blog. Para permitir eso, verifica el tamaño de la imagen utilizando la función de PHP getimagesize(). Dado que esta función estaba abriendo otra conexión http al servidor para obtener la imagen, cada solicitud de abcreaba otra solicitud internamente desde PHP. Como estaba usando todas las ranuras disponibles de mi servidor, estas solicitudes PHP se pusieron en la cola, pero Apache nunca pudo acceder a ellas porque todos sus procesos estaban bloqueados con la solicitud original esperando una ranura para completar la solicitud interna de PHP.

Básicamente, PHP estaba poniendo mi servidor en un estado de bloqueo, y Apache solo comenzaría a funcionar normalmente después de que estas conexiones agotaran el tiempo de espera de su solicitud "secundaria".

Después de eliminar esta función de mi tema, ahora puedo hacer que abmi servidor tenga tantas conexiones concurrentes como quiera, y Apache las está poniendo en cola como se esperaba.


Gracias por publicar esto aquí, he estado tratando de resolver un problema con exactamente los mismos síntomas durante algunos días, ¡creo que también tenemos un elenco de puntos muertos!
James Yale

cómo determinó esto, estoy principalmente interesado en los registros y las herramientas que utilizó para determinar la solicitud de salida secundaria.
Anirudh Goel

2

Lo que está sucediendo aquí es que tiene 25 hilos capaces de aceptar conexiones, y está enviando 26 solicitudes concurrentes. Esa última solicitud se encuentra en la cola de socket según el tamaño de su cartera de pedidos.

El segundo problema es que lo que sea que esté ejecutando, que demore de 2 a 3 segundos, demore lo suficiente como para responder que las 25 conexiones concurrentes lo están ralentizando. sleep (1) podría funcionar, pero, algo en lo que está haciendo el bloqueo de archivos o el bloqueo de tablas desde mysql, cada solicitud paralela puede estar esperando antes de completarse hasta que lleguen al tiempo de espera de 45 segundos.

23mb suena pequeño para un proceso de apache con mod_php y cualquier módulo cargado, por lo tanto, sospecho que podría estar viendo que esos procesos de apache toman un poco más de memoria RAM a medida que se ejecuta su aplicación. Realmente no puedes hacer matemáticas con MaxClients y una memoria así ... estará algo cerca, pero nunca se sabe.

www-data  1495  0.1  0.9  56288 19996 ?        S    15:48   0:01 /usr/sbin/apache2 -k start
www-data  1500  0.0  0.5  49684 12436 ?        D    15:48   0:00 /usr/sbin/apache2 -k start

Hay una máquina, procesos de 56M y 49M.

otra maquina:

www-data  7767  0.1  0.1 213732 14840 ?        S    14:55   0:08 /usr/sbin/apache2 -k start
www-data  8020  0.2  0.1 212424 13660 ?        S    14:57   0:08 /usr/sbin/apache2 -k start

otra maquina:

www-data 28509  0.8  0.1 161720 10068 ?        S    14:39   0:43 /usr/sbin/apache2 -k start
www-data 28511  0.8  0.1 161932 10344 ?        S    14:39   0:43 /usr/sbin/apache2 -k start

Por lo tanto, el uso de la memoria depende mucho de la tarea, qué módulos se cargan, etc. En los dos últimos, creo que hemos deshabilitado pdo y pdo_mysql ya que esa aplicación no los usa.

La verdadera pregunta es, ¿qué estás haciendo que te toma 3 segundos? En el mundo de hoy, eso es una eternidad y se considera una aplicación de 'bloqueo'. Apache normalmente no morirá, pero dejará esos subprocesos en la cola de pedidos pendientes hasta que pueda atenderlos o se agote el tiempo de espera de las solicitudes de espera. Creo que su aplicación probablemente está causando que apache se agote. Pruébelo en una página que contenga solo phpinfo (); y ver si los resultados son los mismos.


¡Gracias por todos los consejos! Sé que todavía necesito optimizar muchas cosas (recién comencé a configurar el servidor hace un par de días y es mi primera experiencia con un VPS), pero el problema fue más profundo que eso ... Publiqué una respuesta a pregunta explicando cuál era el problema en mi caso específico.
Rodrigo Sieiro
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.