2010-09-05 17 views
8

Tengo una aplicación básica de servidor Java que tiene 100 subprocesos de trabajo que hacen solicitudes HEAD simples en las URL. Estoy usando HttpClient 4.x para esto.¿No se puede descargar el hilo? ¿Alguna idea de por qué mi aplicación bloquea?

A los pocos minutos de correr mi programa se congela por un par de minutos y no puedo entender por qué. Echa un vistazo a la captura de pantalla de lo que informa el monitor de vm visual. Puedes verlo plano. Durante este tiempo, no puedo obtener un buen volcado de hebras y el visual vm simplemente se congela hasta que se desbloquea. ¿Alguien tiene alguna idea sobre lo que puedo hacer para tratar de comenzar a depurar a este tipo?

Visual VM: http://tinypic.com/view.php?pic=2i915bs&s=7

Aquí está la salida cuando trataba de tomar un vertedero jstack mientras que estaba congelado:

jstack -F 4325 
Attaching to process ID 4325, please wait... 
Debugger attached successfully. 
Server compiler detected. 
JVM version is 16.3-b01 
Deadlock Detection: 

No deadlocks found. 

Thread 4557: (state = BLOCKED) 
Error occurred during stack walking: 
sun.jvm.hotspot.debugger.DebuggerException: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp 
    at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.execute(LinuxDebuggerLocal.java:152) 
    at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet(LinuxDebuggerLocal.java:466) 
    at sun.jvm.hotspot.debugger.linux.LinuxThread.getContext(LinuxThread.java:65) 
    at sun.jvm.hotspot.runtime.linux_amd64.LinuxAMD64JavaThreadPDAccess.getCurrentFrameGuess(LinuxAMD64JavaThreadPDAccess.java:92) 
    at sun.jvm.hotspot.runtime.JavaThread.getCurrentFrameGuess(JavaThread.java:256) 
    at sun.jvm.hotspot.runtime.JavaThread.getLastJavaVFrameDbg(JavaThread.java:218) 
    at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:76) 
    at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) 
    at sun.jvm.hotspot.tools.JStack.run(JStack.java:60) 
    at sun.jvm.hotspot.tools.Tool.start(Tool.java:221) 
    at sun.jvm.hotspot.tools.JStack.main(JStack.java:86) 
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 
    at java.lang.reflect.Method.invoke(Method.java:597) 
    at sun.tools.jstack.JStack.runJStackTool(JStack.java:118) 
    at sun.tools.jstack.JStack.main(JStack.java:84) 
Caused by: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp 
    at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet0(Native Method) 
    at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.access$800(LinuxDebuggerLocal.java:51) 
    at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$1GetThreadIntegerRegisterSetTask.doit(LinuxDebuggerLocal.java:460) 
    at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.run(LinuxDebuggerLocal.java:127) 
+0

También tengo este problema y parece (sin garantía) que ocurre principalmente en jvms de 64 bits. – whiskeysierra

+0

¿las solicitudes van todas al mismo servidor? (es decir, ¿está seguro de que no es el servidor el que no responde a la solicitud?) –

Respuesta

0

Muy likley debido al exceso de uso de la memoria GC causando. Añadir los parametros de java:

-verbosegc -XX:+PrintGCDetails 

y ver si nota algo obvio en la salida/logs

+0

La captura de pantalla muestra menos de 100 MB utilizados y 0 actividad de GC. –

4

he visto varios informes de errores sobre jstack en Linux con una traza similar:

¿Obtiene el mismo resultado con un kill -3 <pid>?

0

Lo que funcionó para mí fue ejecutar jstack como propietario del proceso sin-F.

Cuestiones relacionadas