2010-09-05 5 views
8

Ich habe eine grundlegende Java-Server-App, die 100 Worker-Threads hat, die einfache HEAD-Anfragen auf URLs ausführen. Ich verwende HttpClient 4.x dafür.Thread-Dump nicht möglich? Irgendwelche Ideen, warum meine App blockiert?

Ein paar Minuten in den Lauf friert mein Programm nur für ein paar Minuten und ich kann nicht herausfinden, warum. Sehen Sie sich den Screenshot an, über den Visual Visual Monitor berichtet. Sie können es flach sehen. Während dieser Zeit kann ich keinen guten Thread-Dump bekommen und visual vm friert nur ein, bis es entsperrt ist. Hat jemand irgendwelche Ideen, was ich tun kann, um zu versuchen, diesen Kerl zu debuggen?

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

Hier ist die Ausgabe als ich versuchte, eine jstack Dump zu nehmen, während es gefroren war:

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

Ich habe auch dieses Problem und es scheint (keine Garantie), dass es vor allem auf 64-Bit-jvms passiert. – whiskeysierra

+0

gehen die Anfragen alle auf den gleichen Server? (d. h. bist du sicher, dass es nicht der Server ist, der nicht auf die Anfrage reagiert?) –

Antwort

0

Sehr likley wegen zu viel Speichernutzung verursacht GC. Fügen Sie die params zu java:

-verbosegc -XX:+PrintGCDetails 

Und sehen, ob Sie etwas offensichtlich in der Ausgabe bemerken/logs

+0

Der Screenshot zeigt weniger als 100 MB verwendet und 0 GC-Aktivität. –

4

Ich habe mit einer ähnlichen Spur mehrere Berichte über Programmfehler jstack auf Linux gesehen:

Erhalten Sie das gleiche Ergebnis mit einer kill -3 <pid>?

0

Was für mich funktionierte, war jstack als Prozesseigner ohne-F.

Verwandte Themen