Herramienta/herramienta de análisis de volcado de subprocesos

Question

Cuando la aplicación Java se cuelga, ni siquiera conoce el caso de uso que conduce a esto y desea investigar, entiendo que los volcados de subprocesos pueden ser útiles.

Pero, ¿cómo podemos derivar fácilmente datos útiles de los volcados de hilo para encontrar dónde está el problema? La aplicación de servidor con la que he estado trabajando genera volcados de subprocesos muy largos, porque es una arquitectura EJB y los volcados de subprocesos contienen muchos subprocesos de contenedor que no estoy seguro de que deba tener en cuenta (es decir, subprocesos que no ejecutan mi código de aplicación , pero el código de JBoss).

Ayer probé la herramienta Thread Dump Analyzer. La herramienta es definitivamente mejor que mirar los volcados de hilo sin procesar en un editor de texto, porque puedes filtrar los hilos que no te interesan, ver la lista de hilos, hacer clic en un hilo para ver sus detalles, comparar los volcados de hilo para encontrar larga duración hilos, etc. Ver captura de pantalla siguiente:

pero todavía hay demasiados datos para analizar - cerca de 300 hilos. No conozco ningún criterio que pueda utilizar para filtrar todos los hilos de JBoss, en los que no estoy interesado. No estoy seguro de si debería estar viendo los hilos que están actualmente en estado "ejecutable" solamente o si "esperar en condición" y "en Object.wait" también son importantes.

¿Cuál es el enfoque que normalmente seguiría y las herramientas que usaría en general?

Answer 1

Un solo conjunto de volcados de hilo no será demasiado útil para llegar a la causa raíz.

El truco consiste en tomar 4 o 5 series de vuelcos de hilo en un intervalo de 5 segundos entre cada uno. así que al final tendrá un solo archivo de registro que tiene alrededor de 20 a 25 segundos de acción en el servidor de la aplicación.

Lo que quiere comprobar es cuando ocurre un hilo atascado o una transacción de larga ejecución, todos los volcados de hilo mostrarán que cierta identificación de subproceso está en la misma línea en su rastro de pila de Java. En términos más simples, la transacción (por ejemplo, en un EJB o base de datos) se extiende a través de múltiples volcados de hilo y, por lo tanto, necesita más investigación.

Ahora, cuando los ejecuta a través de Samurai (no he utilizado TDA), los resaltará en color rojo para que pueda hacer clic rápidamente en él y llegar a las líneas que muestran problemas.

Vea un ejemplo de this here. Mire la imagen de salida de Samurai en ese enlace. Las células verdes están bien.Las celdas rojas y grises necesitan mirar.

un samurai ejemplo de mi propia aplicación web muestra una secuencia de pegado para Thread'19' través de un intervalo de 5 - 10 segundos

>  Thread dump 2/3 "[ACTIVE] ExecuteThread: '19' for queue: 
> 'weblogic.kernel.Default 
> (self-tuning)'" daemon prio=7 
> tid=07b06000 nid=108 lwp_id=222813 
> waiting for monitor entry 
> [2aa40000..2aa40b30]  
> java.lang.Thread.State: BLOCKED (on 
> object monitor)  at 
> com.bea.p13n.util.lease.JDBCLeaseManager.renewLease(JDBCLeaseManager.java:393) 
> - waiting to lock <735e9f88> (a com.bea.p13n.util.lease.JDBCLeaseManager) 
> at 
> com.bea.p13n.util.lease.Lease$LeaseTimer.timerExpired(Lease.java:229) 

...

> Thread dump 3/3 "[ACTIVE] 
> ExecuteThread: '19' for queue: 
> 'weblogic.kernel.Default 
> (self-tuning)'" daemon prio=7 
> tid=07b06000 nid=108 lwp_id=222813 
> waiting for monitor entry 
> [2aa40000..2aa40b30]  
> java.lang.Thread.State: BLOCKED (on 
> object monitor)  at 
> com.bea.p13n.util.lease.JDBCLeaseManager.renewLease(JDBCLeaseManager.java:393) 
> - waiting to lock <735e9f88> (a com.bea.p13n.util.lease.JDBCLeaseManager) 
> at 
> com.bea.p13n.util.lease.Lease$LeaseTimer.timerExpired(Lease.java:229) 

actualización

Recientemente utilicé el Java Thread Dump Analyzer mencionado in this answer y ha sido muy útil para Tomcat en lugar de Sa murai

Answer 2

No estoy seguro de si debería estar mirando a hilos que se encuentran actualmente en el estado de "ejecutable", sólo o si "a la espera con la condición de" y "en Object.wait" son también es importante.

Los dos últimos son en realidad los cosas para buscar la hora de diagnosticar un callejón sin salida, ya que parece que están haciendo. "Ejecutable" significa que el hilo está haciendo algo ahora (o esperando obtener la CPU). "bloqueado" y "esperando" es de lo que están hechos los puntos muertos.

Por supuesto, un contenedor de aplicaciones tendrá muchos hilos esperando legítimamente. Para filtrar los casos interesantes, mira el rastro de la pila. Si se trata de clases de framework (especialmente las llamadas "Worker" o "Queue"), probablemente esté bien. Si se trata de un código de aplicación, deberías mirarlo más de cerca.

Answer 3

Sé que esta es una vieja pregunta, pero acabo de escribir una herramienta para ayudar a que los volcados largos de hilos sean más legibles.

Java Thread Dump Analysis Tool

esta herramienta grupos de hilos juntos, que tienen la misma traza de la pila y le permite sólo Temas Mostrar que están en estados particulares (por ejemplo Ejecutable o bloqueado).

Esto hace que sea un poco más rápido encontrar los hilos interesantes entre las decenas o cientos de subprocesos de JBoss que pasan la mayor parte del tiempo esperando trabajo en el mismo lugar en el código y por lo tanto todos tienen el mismo seguimiento de pila.