Herramienta para analizar grandes volcados de Java.

yourkit

Question

Tengo un volcado de pila HotSpot JVM que me gustaría analizar. La máquina virtual se ejecutó con -Xmx31g , y el archivo de volcado del montón tiene un tamaño de 48 GB.

• Ni siquiera lo intentaré, ya que requiere aproximadamente cinco veces la memoria del montón (que en mi caso serían 240 GB) y es muy lento.
• Eclipse MAT se bloquea con una ArrayIndexOutOfBoundsException después de analizar el volcado de ArrayIndexOutOfBoundsException dinámico durante varias horas.

¿Qué otras herramientas están disponibles para esa tarea? Lo mejor sería un conjunto de herramientas de línea de comando, que consiste en un programa que transforma el volcado de pila en estructuras de datos eficientes para el análisis, combinado con varias otras herramientas que funcionan con los datos preestructurados.

Answer 1

Algunas opciones más:

Esta persona http://blog.ragozin.info/2015/02/programatic-heapdump-analysis.html

escribió un analizador de pila Netbeans personalizado que solo expone una interfaz de "estilo de consulta" a través del archivo de volcado de pila, en lugar de cargar el archivo en la memoria.

https://github.com/aragozin/jvm-tools/tree/master/hprof-heap

Aunque no sé si "su lenguaje de consulta" es mejor que el eclipse OQL mencionado en la respuesta aceptada aquí.

JProfiler 8.1 ($ 499 para licencia de usuario) también se said que puede atravesar grandes montones sin usar mucho dinero.

Answer 2

En caso de usar MAT en MAC (OSX), tendrá el archivo MemoryAnalyzer.ini en MemoryAnalyzer.app/Contents/MacOS. No estaba funcionando para mí. Puede crear un comando de inicio / script de shell modificado basado en el contenido de este archivo y ejecutarlo desde ese directorio. En mi caso quería un montón de 20 GB:

./MemoryAnalyzer -startup ../../../plugins/org.eclipse.equinox.launcher_1.3.100.v20150511-1540.jar --launcher.library ../../../plugins/org.eclipse.equinox.launcher.cocoa.macosx.x86_64_1.1.300.v20150602-1417  -vmargs -Xmx20g --XX:-UseGCOverheadLimit -Dorg.eclipse.swt.internal.carbon.smallFonts -XstartOnFirstThread

Simplemente ejecute este comando / secuencia de comandos desde el directorio Contenido / MacOS a través del terminal, para iniciar la GUI con más RAM disponible.

Answer 3

La respuesta aceptada a esta pregunta relacionada debe proporcionarle un buen comienzo (utiliza histogramas de jmap en vivo en lugar de volcados de pila):

Método para encontrar pérdida de memoria en grandes volcados de almacenamiento dinámico de Java

La mayoría de los otros analizadores de pilas (yo uso IBM http://www.alphaworks.ibm.com/tech/heapanalyzer ) requieren al menos un porcentaje de RAM más que la pila si espera una buena herramienta de GUI.

Aparte de eso, muchos desarrolladores utilizan enfoques alternativos, como el análisis de pila en vivo para tener una idea de lo que está pasando.

¿Aunque debo cuestionar por qué tus montones son tan grandes? El efecto sobre la asignación y la recolección de basura debe ser masivo. Apostaría a que un gran porcentaje de lo que está en tu montón debería estar almacenado en una base de datos / un caché persistente, etc.

Answer 4

Normalmente, lo que uso es ParseHeapDump.sh incluido en Eclipse Memory Analyzer y se describe here , y lo hago en uno de nuestros servidores más reforzados (descargue y copie sobre la distribución linux .zip, descomprima allí). El script de shell necesita menos recursos que el análisis del montón de la GUI, además puede ejecutarlo en su servidor robusto con más recursos (puede asignar más recursos agregando algo como -vmargs -Xmx40g -XX:-UseGCOverheadLimit al final del última línea del script. Por ejemplo, la última línea de ese archivo podría tener este aspecto después de la modificación

./MemoryAnalyzer -consolelog -application org.eclipse.mat.api.parse "$@" -vmargs -Xmx40g -XX:-UseGCOverheadLimit

Ejecútelo como ./path/to/ParseHeapDump.sh ../today_heap_dump/jvm.hprof

Después de que tenga éxito, crea una serie de archivos de "índice" junto al archivo .hprof.

Después de crear los índices, trato de generar informes a partir de eso y los escribo en mis máquinas locales y trato de ver si puedo encontrar al culpable solo por eso (no solo los informes, no los índices). Aquí hay un tutorial sobre cómo crear los informes .

Ejemplo de informe:

./ParseHeapDump.sh ../today_heap_dump/jvm.hprof org.eclipse.mat.api:suspects

Otras opciones de informe:

org.eclipse.mat.api:overview y org.eclipse.mat.api:top_components

Si esos informes no son suficientes y si necesito algo más de excavación (es decir, a través de oql), escribo los índices y el archivo hprof en mi máquina local, y luego abro el volcado de pila (con los índices en el mismo directorio que el volcado de pila) con mi GU de Eclipse MAT. A partir de ahí, no necesita demasiada memoria para ejecutarse.

EDITAR: Me ha gustado añadir dos notas:

• Por lo que sé, solo la generación de índices es la parte que hace un uso intensivo de la memoria de Eclipse MAT. Una vez que tenga los índices, la mayor parte de su procesamiento de Eclipse MAT no necesitará tanta memoria.
• Hacer esto en un script de shell significa que puedo hacerlo en un servidor sin cabeza (y normalmente también lo hago en un servidor sin cabeza, porque normalmente son los más poderosos). Y si tiene un servidor que puede generar un volcado de pila de ese tamaño, es probable que tenga otro servidor que también pueda procesar una gran cantidad de volcado de pila.

Answer 5

Sugiero probar tu kit. Por lo general, necesita un poco menos de memoria que el tamaño del volcado de almacenamiento dinámico (lo indexa y usa esa información para recuperar lo que desea)

Answer 6

Una herramienta no tan conocida: http://dr-brenschede.de/bheapsampler/ funciona bien para grandes montones. Funciona por muestreo, por lo que no tiene que leer todo, aunque un poco meticuloso.