php - optimize - Apache usa una CPU excesiva
optimizar apache2 (5)
Ejecutamos un sitio de tamaño mediano que obtiene unos cientos de miles de vistas de página por día. Hasta el último fin de semana corrimos con una carga generalmente inferior a 0.2 en una máquina virtual. El sistema operativo es Ubuntu.
Al implementar la última versión de nuestra aplicación, también hicimos un apt-get dist-upgrade antes de implementarlo. Después de desplegarnos, notamos que la carga en la CPU había aumentado drásticamente (a veces llegando a 10 y deteniéndose para responder a las solicitudes de página).
Intentamos descargar un minuto completo de los datos de perfilado de Xdebug desde PHP, pero al revisarlo se revelaron solo algunas partes algo lentas, pero nada que explicara el gran salto.
Ahora estamos bastante seguros de que nada en la nueva versión de nuestro sitio web está desencadenando el problema, pero no tenemos manera de estar seguros. Hemos revertido muchos de los cambios, pero el problema aún persiste.
Cuando observamos los procesos, vemos que los procesos Apache individuales utilizan bastante CPU durante un período de tiempo más largo que el estrictamente necesario. Sin embargo, cuando usamos strace en el proceso afectado, nunca vemos nada más que
accept(3,
y se cuelga por un tiempo antes de recibir una nueva conexión, por lo que no podemos ver realmente lo que está causando el problema.
La pila es PHP 5, Apache 2 (prefork), MySQL 5.1. La mayoría de las cosas pasan por Memcached. Hemos probado APC y eAccelerator.
Entonces, ¿cuál debería ser nuestro siguiente paso? ¿Hay algún método de creación de perfiles que ignoramos / desconocemos?
¿Quizás usabas MPM de trabajador antes y ahora no?
Sé que PHP5 no funciona con Worker MPM. En mi servidor Ubuntu, PHP5 solo se puede instalar con Prefork MPM. Parece que el módulo PHP5 no es compatible con la versión multihilo de Apache.
Encontré un enlace aquí que le mostrará cómo obtener un mejor rendimiento con mod_fcgid
Para ver qué trabajador MPM se ve aquí .
La respuesta terminó siendo no relacionada con Apache. Como mencioné, estábamos en una máquina virtual. Nuestras sesiones de usuarios son bastante grandes (creo que 500kB por usuario activo), así que teníamos mucho disco IO. El disco estaba casi lleno, lo que significa que Ubuntu pasó mucho tiempo moviendo las cosas (o eso creemos). No había una forma sencilla de extender el disco (porque no estaba configurado correctamente para VMWare). Esto mató por completo el rendimiento, y Apache y MySQL de vez en cuando usaban 100% de CPU (durante un tiempo muy corto), y el sistema tardaría tanto en actualizar los medidores de uso de la CPU que parecían estar bloqueados allí.
Terminamos configurando una nueva máquina virtual (que también nos dio la oportunidad de documentar todo en el servidor). En la nueva máquina virtual asignamos mucho espacio en disco y movimos sesiones a la memoria (usando memcached). Nuestra carga se redujo a 0.2 en el uso fuera del pico y alrededor de 1 cerca del uso máximo (en una VM de 2 CPU). Al mover las sesiones a memcached, nos quedamos sin disco (estábamos constantemente usando aproximadamente 2MB / s de disco IO, lo cual es muy malo).
Conclusión; a veces solo tienes que empezar de nuevo ... :)
Otra opción que no puedo asegurarle hará ningún bien, pero vale la pena el esfuerzo. Es leer el registro de cambios detallado de la nueva versión y revisar lo que podría haber cambiado y que podría afectarlo remotamente.
Revisar los registros de cambios me ha salvado más de una vez. Especialmente cuando algunas opciones de configuración han cambiado y cuando algo se ha depreciado. El peor caso es que le dará algunas pistas sobre dónde mirar después
Usaría dTrace para resolver este misterio ... si se ejecutara en Solaris o Mac ... pero dado que Linux no lo tiene es posible que desee probar su Systemtap , sin embargo, no puedo decir nada sobre su usabilidad desde No lo he usado
Con dTrace, podría olfatear fácilmente a los culpables dentro de un día, y espero que con Systemtap sea similar
Ver una llamada a accept () desde su proceso Apache no es en absoluto inusual: es el servidor web que espera una nueva solicitud.
En primer lugar, desea establecer cuáles son los parámetros de la carga. Algo como
vmstat 1
le mostrará lo que su sistema está haciendo. Mire en las columnas ''swap'' e ''io''. Si ve algo que no sea ''0'' en las columnas ''si'' y ''so'', su sistema se intercambiará debido a una condición de poca memoria. Considere reducir la cantidad de hijos de Apache en ejecución, o lanzar más RAM en su servidor.
Si la RAM no es un problema, mira las columnas ''cpu''. Le interesan las columnas ''nosotros'' y ''sy''. Estos le muestran el porcentaje de tiempo de CPU gastado en procesos de usuario o sistema. Un número alto de ''nosotros'' señala con el dedo a Apache o a sus scripts, o potencialmente algo más en el servidor.
Corriendo
top
le mostrará qué procesos son los más activos.
¿Has descartado tu base de datos? La causa más común de carga inesperadamente alta que he visto en la producción Las pilas LAMP se reducen a las consultas de la base de datos. Es posible que haya implementado un nuevo código con una consulta costosa; o llegaste al punto en el que hay suficientes filas en tu conjunto de datos para que las consultas previamente baratas se vuelvan caras.
Durante períodos de alta carga, haz
echo "show full processlist" | mysql | grep -v Sleep
para ver si hay consultas de larga ejecución, o un gran número de la misma consulta operando a la vez. Otras herramientas de mysql te ayudarán a optimizarlas.
Puede que le resulte útil configurar y usar mod_status para Apache, lo que le permitirá ver qué pedido realiza cada hijo de Apache y durante cuánto tiempo lo ha estado haciendo.
Finalmente, obtenga una configuración de monitoreo estadístico a largo plazo. Algo como zabbix es sencillo de configurar y le permitirá monitorear el uso de recursos a lo largo del tiempo, de modo que si las cosas se vuelven lentas, tiene líneas de base históricas para comparar y una mejor versión de cuándo comenzaron los problemas.