Determinar el motivo de un proceso detenido en Linux

Question

Estoy tratando de determinar el motivo de un proceso detenido en Linux. Es una aplicación de telecomunicaciones que funciona bajo una carga bastante pesada. Hay un proceso separado para cada uno de los 8 tramos T1. De vez en cuando, uno de los procesos será muy poco receptivo, hasta unos 50 segundos antes de que se anote un evento en el registro del proceso normalmente muy ocupado.

Es probable que algún recurso del sistema se ejecute brevemente. Lo obvio, el uso de la CPU, parece estar bien.

¿Qué utilidades de linux pueden ser las mejores para capturar y analizar este tipo de cosas, y ser lo más discreto posible, ya que este es un sistema muy cargado? Tendría que ser procesos más que orientados al sistema, parecería. Tal vez el monitoreo continuo de/proc/pid/XX? Top no parece ser demasiado útil aquí.

Answer 1

Puede ejecutar el programa en cuestión y ver qué llamadas del sistema está realizando.

Answer 2

Si usted es capaz de detectar este "momento de la falta de respuesta", entonces es posible utilizar strace para insertarse en el proceso en cuestión durante ese tiempo y tratar de averiguar de dónde "duerme":

strace -f -o LOG -p <pid> 

más ligero, pero menos fiable método:

1. Cuando se bloquea el proceso, el uso superior/GP/PIB/strace/ltrace para conocer el estado del proceso (por ejemplo, si se espera en "seleccionar" o consume el 100% CPU en alguna llamada de biblioteca)

2. Conociendo la naturaleza general de la llamada en cuestión, adapte la invocación de strace para registrar llamadas de syscalls específicas o grupos de syscall. Por ejemplo, para registrar llamadas al sistema relacionadas con el acceso de sólo archivo, utilice:

   strace -e file -f -o LOG .... 
   

Si el strace es una herramienta demasiado pesado para usted, trate de vigilancia:

1. uso de memoria con "vmstat 1>/some/log" - tal vez el proceso está siendo intercambiada en (o fuera) durante ese tiempo

2. uso IO con vmstat/iotop - tal vez algún otro proceso está tHRASHING los discos

3. /proc/interrupts - tal vez el controlador de su tarjeta T1 está teniendo problemas?

Answer 3

Thanks - strace sounds useful. Capturar el proceso en el momento correcto será parte de la diversión. Se me ocurrió un plan para escribir periódicamente una marca de tiempo en la memoria compartida, luego monitorear con otro proceso. El envío de un SIGSTOP me permitiría al menos examinar la pila de aplicaciones con gdb. No sé si el esfuerzo en un proceso en pausa me dirá mucho, pero tal vez pueda entonces ponerme en marcha y ver qué dice. O enciéndase y golpee el proceso con un SIGCONT.