Un bajo consumo de CPU durante pruebas no significa que todo vaya bien.

Un monitoreo pobre durante las pruebas de QA se traduce en problemas y dolores de cabeza en producción, en especial, para los administradores. En las aplicaciones basadas en Java, existen componentes intrínsecos a los servidores de aplicaciones/JVM, como el GC. También existen los componentes de las aplicaciones, como los hilos http o las conexiones abiertas hacia base de datos o ldaps.

Es importante tener la visión completa desde que llega una petición hasta que ésta es retornada. Tengo que decir que debemos ser cuidadosos con los costos de la demasía en el monitoreo, en especial, por el overhead que ésto conlleva. En papel o en una herramienta de software, es posible realizar un mapa con las dependencias a otros servicios, la interacción que tiene; el cual posteriormente podemos anexar en el test plan. Ésto nos ayudará a plasmar y detectar los sitios donde colocaremos nuestros scripts recolectores.

El leitmotiv de este post es describir la importancia de mirar las entrañas de la JVM durante pruebas. A través de los años y de mirar constantemente lo que sucede con el heap, me es posible "olerme" cuando algo va mal.

En la imagen anterior, podemos observar que la creación de objetos es excesiva, misma que saturará al la zona de memoria "madura" del heap (memory leaks). Esto fastidiará al GC, acarreando caídas de la aplicación por un gc overhead limit exceeded. Demás está decir que ésto no dejará a ningún usuario contento.

Como es bien sabido, el JDK de Oracle viene con algunas herramientas de monitoreo, como JConsole y JVisual. Quiero hacer notar en las siguientes imagenes que no es posible detectar el comportamiento anómalo con mirar simplemente las estadísticas del sistema operativo, puesto que el proceso consumirá el 30% de procesador, no obstante, es el GC quien consume los recursos, mientras la aplicación tiene una muerte cerebral.

 

 

Como se observa en las imagenes anteriores, la gráfica del consumo de CPU muestra que la línea naranja (aplicación/app server) consume los primeros recursos. Posteriormente, la línea azul (GC) es la responsable de el consumo total de CPU del proceso. En las gráficas del heap, podemos ver que por más que el GC se esfuerce, la recolección de objetos es mínima e insuficiente. Ninguna aplicación que se comporte como la descripción anterior debe pasar a producción.