poner - set border java

Herramienta/método de análisis de volcado de hilo

Question

Cuando la aplicación Java se cuelga, ni siquiera conoce el caso de uso que lleva 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 hilos de larga ejecución, etc. Vea la siguiente captura de pantalla:

Pero todavía hay demasiados datos para analizar, casi 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

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.

Los dos últimos son en realidad los elementos a tener en cuenta al diagnosticar un punto muerto, como parece estar 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 2

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.

Herramienta de análisis de volcado de subprocesos de Java

Esta herramienta agrupa los hilos que tienen la misma traza de pila y le permite mostrar únicamente los hilos que están en estados particulares (por ejemplo, RUNNABLE o BLOCKED).

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 de su tiempo esperando trabajo en el mismo lugar del código y, por lo tanto, todos tienen el mismo seguimiento de pila.

Answer 3

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

El truco es 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 desea verificar es cuándo ocurre un hilo atascado o una transacción de larga ejecución, todos los volcados de hilo mostrarán que un determinado identificador de hilo está en la misma línea en el rastreo de la 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 ejecutas a través de Samurai (no he utilizado TDA), los resaltará en color rojo para que puedas hacer clic rápidamente en él y llegar a las líneas que muestran los problemas.

Vea un ejemplo de esto aquí . 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 ejemplo de Samurai de mi propia aplicación web a continuación muestra una secuencia atascada para Thread''19 ''en un lapso de 5 a 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)

actualizar

Recientemente utilicé el Java Thread Dump Analyzer mencionado en esta respuesta y ha sido muy útil para Tomcat en lugar de Samurai