java - generate - Toma de vertederos de hilo en producción.

thread dump java

Question

Estoy analizando las diferencias entre los enfoques para tomar volcados de hilo. A continuación se muestran los que estoy investigando.

1. Definición de un bean jmx que activa jstack a través de Runtime.exec () al hacer clic en una operación de bean declarada.

2. El subproceso del daemon que ejecuta "ManagementFactory.getThreadMXBean (). DumpAllThreads (true, true)" repetidamente después de un intervalo predefinido.

Al comparar las salidas de volcado de subprocesos entre los dos, veo las siguientes desventajas con el enfoque 2

1. Los volcados de hilo registrados con el enfoque 2 no pueden analizarse mediante analizadores de volcado de hilo de código abierto como TDA
2. La salida no incluye el ID de subproceso nativo, lo que podría ser útil para analizar los problemas de alta cpu (¿verdad?)
3. ¿Nunca más?

Me gustaría recibir sugerencias / aportaciones sobre

1. ¿Hay alguna desventaja de ejecutar jstack a través de Runtime.exec () en el código de producción? ¿Algún problema de compatibilidad en varios sistemas operativos: Windows, Linux?

2. ¿Algún otro enfoque para tomar volcados de hilo?

Gracias.

Editar -

Un enfoque combinado de 1 y 2 parece ser el camino a seguir. Podemos tener un subproceso dedicado ejecutándose en segundo plano e imprimiendo los volcados de subprocesos en el archivo de registro en un formato comprendido por los analizadores de volcado de subprocesos. Si se necesita información adicional (como, por ejemplo, probablemente el ID de subproceso nativo) que se registra solo por la salida jstack, lo hacemos manualmente según sea necesario.

Answer 1

Con Java 8 en la imagen, jcmd es el enfoque preferido.

jcmd <PID> Thread.print

A continuación se encuentra el fragmento de la documentación de Oracle :

El lanzamiento de JDK 8 presentó Java Mission Control, Java Flight Recorder y la utilidad jcmd para diagnosticar problemas con JVM y aplicaciones Java. Se sugiere utilizar la última utilidad, jcmd en lugar de la anterior utilidad jstack para mejorar los diagnósticos y reducir la sobrecarga de rendimiento.

Sin embargo, enviar esto junto con la aplicación puede tener implicaciones de licencia, lo cual no estoy seguro.

Answer 2

Le sugiero que haga todo el análisis de almacenamiento dinámico en un entorno de ensayo si existe tal env, y luego refleje el ajuste requerido del Servidor de aplicaciones en la producción, si corresponde. Si necesita los volcados para el análisis de la utilización de la memoria de su aplicación, entonces tal vez debería considerar perfilarla para un mejor análisis.

Los volcados de OutOfMemoryExceptions generalmente se generan como resultado de las OutOfMemoryExceptions de OutOfMemoryExceptions resultantes de las pérdidas de memoria y la mala gestión de la memoria.

Revise la documentación de su Servidor de aplicaciones, la mayoría de los servidores modernos tienen medios para generar volcados en tiempo de ejecución, aparte de la causa normal que mencioné anteriormente, aunque el volcado resultante podría ser específico del proveedor.

Answer 3

Puedes usar

jstack {pid} > stack-trace.log

ejecutándose como usuario en el cuadro donde se ejecuta el proceso.

Si ejecuta esto varias veces, puede usar un diff para ver qué subprocesos están activos más fácilmente.

Para analizar las trazas de la pila, utilizo la siguiente muestra periódicamente en un subproceso dedicado.

 Map<Thread, StackTraceElement[]> allStackTraces = Thread.getAllStackTraces();

Usando esta información, puede obtener el ID del hilo, el estado de ejecución y comparar las trazas de la pila.

Answer 4

Si es un * nix, intentaría kill -3 <PID> , ¿pero entonces necesita conocer el id del proceso y quizás no tenga acceso a la consola?