windows - project visualvm
No se puede utilizar la creación de perfiles JVisualVM para Tomcat7 que se ejecuta como un servicio en Windows7 (4)
¿No puede simplemente conectarse a través de la red, es decir, iniciar la JVM con
java
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=1234
-Dcom.sun.management.jmxremote.local.only=false
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-jar my.jar`
y cree una conexión de red en la herramienta para localhost: 1234
Estoy intentando perfilar un Servlet que se ejecuta en Apache Tomcat (7.0.34) como un servicio en Windows 7 (64 bits) utilizando JVisualVM (JDK 1.7.0 - 06, 64 bits) que se ejecuta localmente.
Inicialmente, tuve el problema de que Tomcat no aparecía en la lista de aplicaciones locales debido a los diferentes errores / características de la propiedad "java.io.tmp", pero solucioné el problema tal como lo indicaron varias publicaciones en este foro.
Sin embargo, aunque el proceso de Tomcat ahora se muestra en la lista de aplicaciones locales como "Aplicación local", cuando abro el proceso, no hay pestañas para Monitor, Threads, Sampler o Profile, solo la pestaña Overview para la cual los argumentos de JVM y las propiedades de Sytem sub -tabs muestra el temido mensaje "no admitido para este jvm".
He verificado dos veces los siguientes artículos:
- que tanto Tomcat como JVisualVM ejecutan la misma versión de Java mirando las propiedades de JVM en JVisualVM (usando una conexión JMX para Tomcat)
- que tanto Tomcat como JVisualVM tienen la misma ruta "java.io.tmp" mirando las Propiedades del sistema en JVisualVM (nuevamente usando una conexión JMX para Tomcat) Y mirando el directorio TMP / TEMP real y confirmando que los archivos PID para ambos existe
- que el sistema de archivos es NTFS
- que el usuario de Windows no tiene un guión bajo en el nombre (Nota: el usuario tiene un punto en el nombre, ya que estamos utilizando los inicios de sesión de red del formulario "nombre de pila", sin embargo no tengo problemas para ver otras aplicaciones de Java en JVisualVM así que no pienses que esto es un problema)
- que tanto Tomcat como JVisualVM se ejecutan como el mismo usuario de Windows al observar los procesos en el Administrador de tareas
Un par de puntos finales:
- Necesito hacer un perfil del Servlet por lo que usar JMX no es suficiente
- Pude hacer un perfil en una máquina con Windows XP (Java 7, Tomcat 7 como servicio), ¿por lo que parece ser una cosa de Windows 7/64 bits?
Si alguien ha tenido y resuelto este problema, obviamente la solución sería muy apreciada. Sin embargo, sería útil saber si otras personas están ejecutando la misma configuración: Windows 7 64 bit, Java 7 64 bit, Tomcat 7 funcionando como un servicio, con éxito .
Actualización: en lugar de ejecutarme como un servicio, ejecuté Tomcat utilizando el archivo por lotes y todo funcionó a la perfección: ¿de qué se trata ejecutar un servicio?
Como ya insinué en mi comentario anterior. Supongo que la respuesta simple es que no es posible . Para realizar la comunicación entre jconsole / jvisualvm y el proceso a monitorear, Java utiliza archivos de memoria asignados. Al final, se reduce a una cierta llamada a la API de Windows que falla debido a la función "Windows Service Hardening" [1] agregada en Windows Vista y que, por supuesto, también existe en Windows 7 y versiones posteriores.
La llamada que falla es a la función OpenFileMapping como se puede ver en perfMemory_windows.cpp línea 1402 [2]. Durante mis experimentos, se llama al método con un argumento de la forma "hsperfdata_ [nombre de usuario] _ [id de proceso]". Como se detalla en la explicación de Microsofts sobre las diferencias introducidas por el fortalecimiento del servicio (ver [3]), la comunicación no funcionará si no se usa el prefijo de nombre: "Si una aplicación de usuario se sincroniza con el servicio creando o abriendo objetos con el prefijo Local / (o sin prefijo, que por defecto es Local), la aplicación ya no funciona como se esperaba ".
Si alguien quiere echar un vistazo él mismo. Puede usar la herramienta Logger [4] incluida con las herramientas de depuración de Windows para rastrear las llamadas a la API.
Además, el Explorador de procesos de Sysinternals es muy útil, ya que muestra los nombres completos utilizados para los archivos asignados a la memoria a través de su función "Buscar identificador o DLL ...". Simplemente busque los controladores que contienen "hsperf".
Como nota al margen: la solución para eliminar o desordenar el directorio temporal que contiene los datos de hsperf se reduce al hecho de que el caso del nombre de usuario utilizado por el proceso que se debe monitorear y el proceso de monitoreo deben ser coherentes. Pero en lugar de cambiar el directorio temporal, también puede cambiar fácilmente la variable de entorno USERNAME utilizada por el proceso de monitoreo. También puede ver cómo se usa en la línea 272 [2] de perfMemory_windows.cpp.
[1] http://technet.microsoft.com/en-us/library/cc507844.aspx#EHF
[3] http://msdn.microsoft.com/en-us/windows/hardware/gg463353.aspx
[4] http://msdn.microsoft.com/en-us/library/windows/hardware/ff560123(v=vs.85).aspx
También me gustaría saber si alguien tiene una solución en Windows 7. Como se señaló, el truco de ejecutar VisualVM como un servicio no funciona en Vista y supongo que las mismas características de seguridad evitan que funcione en Win 7.
La única solución que tengo es configurar su servidor de aplicaciones (Tomcat) como un servicio para que, si se reinicia, el servidor se active y esté disponible. Luego, detenga manualmente el servicio e inicie su servidor de aplicaciones (Tomcat) desde una línea de comandos y conéctese con VisualVM. Entonces tienes una buena supervisión siempre y cuando el servidor no se reinicie.
Casi lo hizo " En lugar de ejecutarlo como un servicio, ejecuté Tomcat utilizando el archivo por lotes y todo funcionó a la perfección: ¿de qué se trata el ejecutar como un servicio? " Ahora, el único paso que queda es ejecutar JVisualVM como servicio :)
Refiera esto
https://blogs.oracle.com/nbprofiler/entry/monitoring_java_processes_running_as
Dado que solo se pueden perfilar los procesos Java que se ejecutan bajo el mismo usuario que VisualVM, la única forma de crear un perfil del servicio de Windows (que se ejecuta de forma predeterminada en la cuenta del sistema) es iniciar el propio VisualVM como un servicio de Windows. Tenga en cuenta que este enfoque no funciona en Windows Vista debido a restricciones de seguridad que, de forma predeterminada, impiden que los servicios muestren cualquier IU.
Otra opción es ejecutar para ejecutar CMD.EXE como sistema local, consulte a continuación.
http://vicevoice.blogspot.in/2009/09/vaas-visualvm-as-service.html