No puedo ver mis propios métodos de aplicación en Java VisualVM

Question

Estoy tratando de crear un perfil de mi aplicación java, solo para descubrir los métodos en los que se gasta la mayor parte del tiempo. Dadas las malas reacciones aquí al TPTP, pensé en darle una oportunidad a Java VisualVM.

Parecía bastante simple de usar, excepto que parece que no puedo obtener nada consistente o útil.

Parece que no veo nada relacionado con MI PROPIO código; todo lo que obtengo es un montón de llamadas a cosas como java. * Métodos.

He intentado restringir la instrumentación solo a mis propios paquetes, lo que parece reducir el número de métodos instrumentados, pero todavía no parece que vea el mío.

Cada vez que corro, obtengo varios métodos instrumentados, que van desde 10 a 1000. Intenté conciliar el sueño al inicio de mi aplicación, para asegurarme de que VisualVM funciona correctamente antes de que mi aplicación comience a hacer algo interesante, para asegurarme de que se está perfilando cuando se está ejecutando algo interesante.

¿Hay algo que deba hacer para asegurar que mis clases se instrumenten? ¿Hay problemas de sincronización? ..like, tiene que esperar que se carguen las clases, etc.? También intenté ejecutar las tripas del código dos veces, para asegurarme de que todo el código se ejerce ...

Solo estoy ejecutando una aplicación, con una fuente principal, de Eclipse. Intenté usar la integración de Eclipse para que VisualVM se inicie cuando inicie la aplicación: los resultados son los mismos. También intenté exportar la aplicación como una aplicación ejecutable, y ejecutarla de forma independiente desde la línea de comandos, en lugar de a través de Eclipse, el mismo resultado.

Mi aplicación no es una aplicación web de larga ejecución, etc. - solo una principal que llama a algunas de mis propias clases para procesar, luego se cierra.

¡Estaría agradecido por cualquier consejo sobre lo que podría estar haciendo mal! :)

Gracias!

Answer 1

Supongo que esto no es solo una cuestión académica: le gustaría ver si puede hacer que la aplicación funcione más rápido. Supongo que tampoco te importaría pensar un poco "fuera de la caja". Hay muchas ideas populares sobre el rendimiento que en realidad son bastante borrosas.

Por ejemplo, dices que estás buscando "métodos en los que se gasta la mayor parte del tiempo". Si con eso quieres decir "tiempo propio" (contador de programa realmente en el método) probablemente haya muy poco, a menos que tengas algunos bucles intensos. Los métodos generalmente pasan tiempo llamando a otros métodos, a veces haciendo I/O.

Otra idea difusa es que medir el tiempo del método o contar el número de llamadas puede decirle mucho sobre dónde están los cuellos de botella. Los cuellos de botella son líneas específicas de código, no de métodos, por lo que incluso si sabes aproximadamente dónde mirar, todavía estás jugando al detective.

Estas son algunas de las ideas difusas. Here is a bunch more. Déjeme sugerir cómo debería pensar , y cómo eso lleva a resultados.

Cuando finalmente arregle algo, reducirá el tiempo de ejecución en un cierto porcentaje, como (elija un número) 30%, ¿verdad? (De lo contrario, no arreglaste nada). De acuerdo, durante ese 30% estuvo haciendo algo, algo que no necesitaba hacer porque luego te deshiciste de él.Entonces, usted no necesita medir. Usted hace necesita averiguar qué está haciendo en ese momento, para que sepa de qué deshacerse.

Una forma muy simple es "pausarla" 10 (o algunas) veces al azar. Comprenda qué está haciendo y por qué, mirando la pila de llamadas y posiblemente algunos de los datos. En aproximadamente 3 de esos momentos lo verá haciendo algo de lo que podría deshacerse.

Conocerá aproximadamente cuánto ahorrará al ver qué porcentaje de muestras lo está mostrando. Aproximado es lo suficientemente bueno. Puede ver exactamente cuánto tiempo se ahorra al cronometrarlo antes y después.

Entonces, no se detenga. Has hecho la aplicación más rápido. Hazlo de nuevo, y hazlo más rápido aún. Tarde o temprano llegas a un punto en el que no puedes hacerlo más rápido, pero probablemente esté en más de un paso.

Answer 2

puede mirar Appdynamics lite, tiene algunas características agradables como el descubrimiento de transacciones comerciales que puede muestrear todas las llamadas realizadas a un método específico en su código.

La versión lite tiene muchas limitaciones, como 10 min de muestreo máximo y 30 business transaction discovery max.

Se sería bueno tener una herramientas gratuitas que hacen lo mismo

Answer 3

yo también estoy luchando con VisualVM, lo cual es una lástima, porque su interfaz de usuario es fantástica, mientras que su producción de perfiles parece horrible. Puedes parecer mi pregunta aquí.

Java VisualVM giving bizarre results for CPU profiling - Has anyone else run into this?

te puedo decir un par de cosas extrañas que he aprendido acerca VisualVM y la forma en que parece hacer su perfilado.

VisualVM parece estar contando el tiempo total dedicado dentro de un método (hora del reloj de pared). Tengo un hilo en mi aplicación que inicia varios otros hilos y luego inmediatamente bloquea esperando un mensaje en una cola. VisualVM no registrará este método en el generador de perfiles hasta que uno de los otros subprocesos envíe el mensaje que estaba esperando el primer subproceso (cuando finaliza la aplicación). De repente, la llamada al método de bloqueo domina la salida del perfil y se registra como que ocupa más del 80% del tiempo de la aplicación.

Otros perfiladores, como JProfiler y el utilizado por Azul, no cuentan un hilo bloqueado como el tiempo que lleva el perfilador. Esto significa que los métodos de bloqueo que probablemente no son interesantes (dependen de la situación) para el perfil de rendimiento están oscureciendo su visión de ese código que está consumiendo su tiempo de CPU.

Cuando estoy corriendo mi perfilado termino con

sun.rmi.transport.tcp.TCPTransport $ ConnectionHandler.run()

oscureciendo mi perfilado justo hasta que el mensaje llega de nuevo a la espera hilo y luego el punto superior se comparte entre estos dos métodos totalmente irrelevantes, así como varios otros métodos poco interesantes que no aparecen en otros perfiladores.

En segundo lugar, y creo que, bastante importante, el mecanismo de filtrado de métodos no funciona como yo esperaba.Esto significa que no puedo filtrar. Estoy intentando rastrear cuál es la historia con esto ahora mismo.

No es una respuesta realmente útil. La solución, como lo veo en este momento, es pagar por JProfiler: VisualVM simplemente no parece confiable para esta tarea.