java - jps - jstack thread state
Jstack y No hay suficiente almacenamiento disponible para procesar este comando (5)
En el pasado, he visto esto cuando la JVM se ejecuta como un Servicio de Windows en Windows 2003.
Primero, verifique si esto es un problema con el directorio TMP .
Segundo, jstack (o las otras utilidades como jconsole) no se conectarán al proceso local a menos que se ejecute en la misma sesión. Si el servicio se ejecuta como un usuario específico, es posible que pueda conectarse iniciando sesión en la misma sesión. Si está utilizando Remote Desktop, puede conectarse utilizando "mstsc / admin" (que solía ser / console) y tratar de ejecutar jstack de nuevo. Definitivamente, compruebe que el directorio TMP esté configurado correctamente si esto no soluciona el problema.
Si el servicio se ejecuta como LocalSystem, el procedimiento anterior probablemente no ayude mucho. No sé si hay una manera de iniciar sesión en la misma sesión que LocalSystem.
Algunas otras alternativas pueden ser configurar el proceso de monitoreo remoto y usar jvisualvm (desde el propio servidor u otra máquina) para conectarse a través de un puerto y hacer un volcado de hilos.
Estoy intentando ejecutar el comando jstack en mi aplicación java. La aplicación es bastante grande, se ejecuta dentro de jboss AS y ocupa unos 4 GB de memoria. El sistema operativo es Windows Server 2003 Standard Edition. Cada vez que aparece un error "No hay suficiente almacenamiento disponible para procesar este comando". Hay suficiente memoria ram, 16gb, y espacio en disco. Entonces, ¿alguna idea?
Este es un mensaje de error del O / S subyacente. No hay mucho que puedas hacer en tu código para lidiar con esto, aparte de atrapar la excepción que se lanza. Boo a Windows por ser tan limitado.
Me encontré con esto recientemente en Win2008r2 y pensé que iba a compartir mi solución, ya que tardé un rato en averiguarlo. El comentario de Rob sobre psexec -s es lo que lo hizo por mí.
Parece que en Vista y más tarde jstack no funciona contra los servicios debido al contexto del usuario. No tiene nada que ver con la memoria. Sospecho que esta es la misma razón por la que las personas han visto este problema en 2003 a través de un escritorio remoto, a menos que use el conmutador / admin o / console en mstsc. A partir de Vista, la seguridad reforzada es probablemente lo que la rompió.
Iniciar mi aplicación desde una ventana de cmd funcionó bien, pero eso no me ayuda a depurar nuestra instalación estándar. Habilitar el puerto de depuración de Java (para VisualVM, Eclipse o la mayoría de los depuradores de Java) requiere un reinicio de la aplicación, por lo que perderá el estado que probablemente está intentando capturar si aún no tiene la depuración habilitada. Iniciar el servicio con mis credenciales de usuario no funcionó, me sorprendió un poco. Pero psexec -s ejecuta jstack desde el contexto del sistema, que funcionó a la perfección. Ah, y necesitará ejecutar psexec desde un indicador de cmd elevado, si UAC está activado.
Tuvimos problemas al ejecutar JStack en una máquina con Windows, incluso con una aplicación modesta (1 GB). Terminamos haciendo nuestro análisis de pila y pila usando Netbeans. Esto pareció hacer frente al análisis de archivos de volcado mucho mejor. YMMV.
Dale a Netbeans una oportunidad para perfilar, es muy bueno. Tenga en cuenta que VisualVM es un perfilador de NB recortado y viene con 6u7.
psexec -s jstack PID >> c:/jstack.log funciona perfectamente en la misma máquina. Por primera vez, tomó un tiempo, pero de nuevo ejecuté con la opción de redireccionar a archivo, se completó en pocos segundos.