Te dejo este post de Andrei Guchín, de Abstracta, sobre cómo utilizar GCeasy para analizar el Garbage Collector de Java como para buscar posibles cuellos de botella y así optimizar aplicaciones. Esto es especialmente útil cuando hacemos pruebas de performance y no solo queremos reportar cuáles son los tiempos de respuesta, sino que queremos ayudar a optimizar el comportamiento del sistema.
El Garbage Collection log (también conocido como GC log) es de los recursos más importantes a analizar a la hora de buscar problemas de memoria de la Java Virtual Machine (JVM) cuando buscamos optimizar la performance de un sistema.
Este log contiene información sobre el comportamiento del Garbage Collector en todas sus acciones (limpieza del área Young Generation, Full GC, etc.). Se puede encontrar por ejemplo: cuándo se ejecuta, cuántas veces, cuánta memoria limpia, cuánta memoria queda en uso, cuánto demora en ejecutar, etc.
El problema es que esta información la expone en líneas que tienen este formato:
1428.323: [GC 2393480K->1395152K(3126720K), 0.0215430 secs] 1435.387: [GC 2404816K->1400394K(3125824K), 0.0215430 secs] 1438.962: [GC 2410058K->1913266K(3127104K), 0.1450010 secs] 1439.108: [Full GC 1913266K->718144K(3127104K), 0.6594300 secs] 1447.015: [GC 1729472K->729832K(3127104K), 0.0177330 secs]
Por lo que, para poder realizar un análisis eficaz, es necesario procesar este log con alguna herramienta.
Durante mucho tiempo estuve usando la herramienta GCViewer, pero la misma expone información muy básica, difícil de entender, y muchas veces tenía problemas en el procesamiento del log debido a los distintos formatos que existen (no es lo mismo la implementación oficial de la JVM que la implementada por IBM). Dejé de tener muchos de estos problemas cuando empecé a usar GCeasy, que es la herramienta que te quiero presentar en este post.
GCeasy
GCeasy es una herramienta online para analizar GC logs. Ellos la definen como un analizador de GC logs universal ya que, aparentemente, es la única herramienta en el mercado que soporta todos los formatos de GC log existentes. No soy capaz de afirmar si de verdad soporta TODOS los formatos, pero hasta ahora no he tenido problemas en procesar ninguno de los logs que he subido.
La forma de utilizarla es muy simple: se accede al sitio gceasy.io, se sube el log en una ventana que aparece del lado derecho de la pantalla y se presiona el botón “Analyze”. Luego la herramienta procesa el log en base a algoritmos de machine learning y devuelve un reporte con el análisis realizado.
Lo primero que se muestra en el reporte es si se detectó algún problema de memoria durante el procesamiento del log. Los algoritmos de machine learning de la herramienta pueden detectar algunos problemas típicos como: memory leaks, pausas del GC muy grandes, muchos Full GC’s consecutivos, etc. En la siguiente imagen se puede ver un ejemplo de un log donde se detectó la ejecución de muchos Full GC’s consecutivos.
Además de una breve explicación del error, se adjunta un link al blog de la herramienta donde se da más detalle del problema y sugerencias para corregirlo.
Seguido a esto, el reporte presenta una serie de gráficas y tablas con información que puede resultar muy útil si se sabe interpretar.
En las sección “Key Performance Indicators” se muestra por ejemplo el Throughput del GC, que es el porcentaje del tiempo procesando transacciones reales vs el tiempo invertido en el GC. Un porcentaje alto indica que el tiempo invertido en GC es poco respecto al tiempo de procesamiento de la transacción. Además en esta sección se muestra el tiempo promedio de pausa (Stop The World) por el GC, el tiempo máximo de pausa y la cantidad de ejecuciones del GC.
En la sección “Interactive Graphs” se muestran varias gráficas dónde entre otras cosas se observa el heap de memoria, cantidad de Full GC’s, duración de los ciclos de GC, etc. Las gráficas resultan muy útiles para detectar memory leaks.
Por último, quería detenerme en la sección “GC Statistics”. Ahí se muestran varias tablas con diferentes métricas del GC. Se pueden ver por ejemplo la cantidad de Full GC’s ejecutados, el tiempo promedio que demoran en ejecutarse, el tiempo de pausas por GC’s, etc., y en base a estos valores evaluar si conviene hacer un tuning del GC para mejorar la performance. A modo de ejemplo, si se observa que el tiempo de ejecución del GC toma valores entre 1 y 3 segundos (o más), es probable que sea necesario realizar algún ajuste para optimizarlo.
Conclusión
GCeasy es una herramienta muy útil a la hora de analizar el manejo de memoria en la JVM. Provee al usuario de información valiosa para diagnosticar problemas típicos relacionados a la memoria, así como para optimizar los ciclos de GC y la performance en general de la aplicación.
En lo personal, creo que las dos grandes ventajas que tiene frente a otras herramientas de este estilo son:
- que acepte cualquier formato de GC log (lo que ahorra bastante tiempo que usualmente se gasta descubriendo en el log qué “no le gusta” a la herramienta y acomodándolo para que funcione)
- y el “auto detector” de problemas que, si bien hay casos particulares en que lo que sugiere no aplica, la mayor parte del tiempo resultan ser sugerencias muy útiles para mejorar la performance o corregir problemas de memoria, en especial para aquellos usuarios que no tienen gran conocimiento del manejo de memoria en la JVM y el funcionamiento del GC.
