Averigüe qué proceso de apache de alto uso de CPU está haciendo realmente

Actualmente tenemos algunos problemas con nuestro servidor donde, de forma intermitente, parece que tenemos procesos de apache que simplemente se ejecutan y se ejecutan, ocupando el 100% de la CPU.

Al ejecutar top, vemos lo siguiente:

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
20788 www-data  20   0  318m  18m 3984 R  100  0.0  40:29.21 /usr/sbin/apache2 -k start
23523 www-data  20   0  319m  20m 4684 R  100  0.0   4:12.36 /usr/sbin/apache2 -k start

Quiero intentar averiguar qué script (o lo que sea) está causando esto, así que intenté:

 strace -p 20788

Pero eso no muestra ningún resultado en absoluto (lo dejé durante unos 10 minutos y no muestra nada). Según tengo entendido, esto podría significar que está atrapado en un bucle infinito y que no hay "llamadas al sistema" para mostrar.

¿Hay algo más que pueda hacer para mostrar lo que está pasando?

Gracias

Editar: olvidé mencionar que este es un servidor en vivo con unos cientos de usuarios a la vez. Por lo tanto, no puedo intentar cambiar libremente las opciones de configuración y reiniciar Apache.

Edición 2: la traza inversa (bt) de gdb no parece ser tan útil cuando PHP no está configurado con --enable-debug - solo muestra "execute ()", pero necesito saber qué es el script PHP realmente corriendo ... ¿hay alguna otra manera?

#0  0x00007f6c143fb0c5 in ?? () from /usr/lib/apache2/modules/libphp5.so
#1  0x00007f6c143b040b in execute () from /usr/lib/apache2/modules/libphp5.so
#2  0x00007f6c1438b970 in zend_execute_scripts () from     /usr/lib/apache2/modules/libphp5.so
#3  0x00007f6c14337fe3 in php_execute_script () from     /usr/lib/apache2/modules/libphp5.so
#4  0x00007f6c1441ae7d in ?? () from /usr/lib/apache2/modules/libphp5.so
#5  0x00007f6c18912508 in ap_run_handler ()
#6  0x00007f6c1891297e in ap_invoke_handler ()
#7  0x00007f6c18922570 in ap_process_request ()
#8  0x00007f6c1891f398 in ?? ()
#9  0x00007f6c18918fa8 in ap_run_process_connection ()
#10 0x00007f6c189271d0 in ?? ()
#11 0x00007f6c1892793a in ?? ()
#12 0x00007f6c189284e7 in ap_mpm_run ()
#13 0x00007f6c188fd4a4 in main ()

Bueno, en caso de que te sientas valiente:

gdb -p 20788

luego emita btpara ver el marco de la pila, por ejemplo

Y por cierto, también hay ltraceque mencionarlo: pruébalo también.

UPD : bueno, ok, ya que ahora tenemos una idea de que Apache realmente está ejecutando algo, ¿por qué no mirarías la mod_statussalida - Extendida ?

Un enfoque muy fácil es usar htop. Puede ordenar los procesos de CPU alta y luego usar

• s para straceun proceso
• l para lsofver los archivos abiertos de un proceso
• L a ltrace.

Descubrí que al menos una de esas opciones encuentra el script que genera la carga y, por supuesto, puede usar esto en un servidor web de producción para depurar.

Tu podrías intentar:

• iotop (mostrando E / S en el sistema)
• netstat -t (mostrando conexiones)
• Eche un vistazo a los archivos de registro de Apache y descubra qué hizo el servidor por última vez
• establezca algunos RLimits para el proceso de apache. Cuando se alcanzan estos límites, el proceso se anulará y le brindará más información.

Su comando debería funcionar siempre que realice una solicitud HTTP que active ese PID.

¿Quizás desee reconfigurar temporalmente Apache con un solo proceso secundario?

El PID de esa instancia de apache es bajo, podría ser el padre de todo el lote. Eso ciertamente explicaría el alto uso de la CPU (se mantiene, otros se generan y se recuperan según la carga). Mucho tiempo de CPU acumulado podría significar que ha estado funcionando durante mucho tiempo. Sin salida de strace(1)solo significa que no hizo llamadas al sistema. Sí, podría estar en un circuito cerrado, pero Apache es esencialmente E / S a través de la red, por lo que creo que no está haciendo nada útil. Extraño 100% de una CPU, en cualquier caso.

Prueba esto:

1) Inicie un registro con fecha / hora, script PHP y el PID usando getmypid()

2) Luego mira tu servidor con top

3) Cuando vea que el proceso de apache se está acelerando, busque la misma fecha / hora y PID en sus registros. Debería poder encontrar el script problemático.