Al observar el resultado de, topnoto que de manera intermitente hay uno o dos procesos de Apache que consumen una gran cantidad de CPU, entre 50 % y 90 %.
Los picos en el uso de la CPU van y vienen con bastante rapidez cada 10 segundos aproximadamente.
Hay varios otros procesos de Apache en ejecución que consumen entre el 2% y el 4%.
He investigado todas las formas de intentar rastrear qué servidor virtual/sitio web es responsable de estos procesos. Sin embargo, debido a que aparecen y desaparecen rápidamente, no puedo encontrar una forma confiable de hacerlo.
Lo intenté lsofy también miré el resultado, server-statuspero debido a que los procesos no duran mucho, el ID del proceso se reutiliza y no es posible vincularlo al host virtual que está causando el problema.
Por ejemplo, si ejecuto lsofel ID de proceso en cuestión, enumera una docena de archivos de registro de host virtual diferentes que han compartido ese ID de proceso en los últimos segundos. Estoy convencido de que hay un host virtual culpable, pero no sé cuál.
También revisé el registro de consultas lentas de MySQL y esto no revela nada de interés.
Respuesta1
Mi recomendación: agregue tiempo de respuesta a sus registros.
No es perfecto, ya que no hay garantía de que las solicitudes que causan picos tarden más en atenderse que otras, pero es probable y le brinda un punto de partida para la investigación.
Para hacer esto, querrá definir un nuevo LogFormat y CustomLog que incluya el parámetro %D. ver el apachedocumentación mod_log_config.
Otra opción que probablemente sea de nivel demasiado bajo pero que podría darle una idea de la naturaleza de la carga sería rastrear el proceso principal de Apache con -f para seguir a los hijos y -c para mostrar el tiempo de CPU por llamada. , p.ejstrace -f -c -p <apache parent pid>
Una vez que conozca las llamadas al sistema que tardan más tiempo, podrá rastrearlas directamente. Por ejemplo, supongamos que el servidor pasa mucho tiempo escribiendo(), entonces usted podría hacerlo strace -f -e trace=write -p <apache parent pid>y observar esas llamadas con más detalle.