2012-04-14 9 views
3

Wir hatten einige Probleme von thread pile ups mit der Produktion Tomcat-Server, also wollte ich einige Cron einrichten, um regelmäßig überprüfen Thread-Dumps und E-Mail senden, wenn etwas nicht stimmt. Um dies zu tun, müssen wir Thread-Dumps in der Datei vom Shell-Skript nehmen, aber ich kann das nicht tun. Von Shell kann ich KILL -3 <PID> in regelmäßigen Abständen ausgeben, aber das Problem ist, dass Dump zu catalina.out geht, das GBs von Daten enthält, wegen denen das Herausziehen nur des Threaddumps schmerzhafter Prozess ist. Einige Diskussionsthreads vorgeschlagen Verwendung von „jstack“ und umleiten Ausgabe in eine Datei, sondern dass auch nicht funktioniert und gibt diesen Fehler:Wie bekomme ich automatisch Thread-Dumps von Tomcat

-bash-3.2# java -version 
java version "1.6.0_26" 
Java(TM) SE Runtime Environment (build 1.6.0_26-b03) 
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) 
-bash-3.2# uname -a 
Linux ip-10-130-225-20 2.6.16.33-xenU #2 SMP Wed Aug 15 17:27:36 SAST 2007 x86_64 x86_64 x86_64 GNU/Linux 

-bash-3.2# sudo /usr/java/jdk1.6.0_24/bin/jstack -F 15668 
Attaching to process ID 15668, please wait... 
Debugger attached successfully. 
Server compiler detected. 
JVM version is 19.1-b02 
Deadlock Detection: 

No deadlocks found. 

Thread 8183: (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) 

Dieser Fehler mit Java-Team offen zu sein scheint.

Gibt es noch andere Vorschläge, Threads intelligent zu erfassen und zu analysieren? Oder Skript, um riesige catalina.out zu parsen und nur Thread-Dumps daraus zu bekommen?

Antwort

0

diskutiert Ein schneller Weg, den ich herausgefunden habe, war (falsch) mit javamelody. Wir verwenden es, um verschiedene Aspekte der Anwendung zu überwachen und es bietet auch visuelle Möglichkeiten, um aktuelle Threads zu sehen, so schrieb ich kleine Shell-Skript, um "http: // IP: PORT/SERVICE/Überwachung? Teil = ThreadsDump" jede Minute und Dump-Antwort in einer Datei. Wenn die Antwort ein blockiertes Thread-Skript enthält, werden alle 5 Sekunden Thread-Dumps ausgeführt. Dies hilft bis zu einem gewissen Grad, aber wenn sich das Problem verschlimmert und der Server blockiert, reagiert Javamelody auch nicht mehr.

Verwandte Themen