TDA - Thread Dump Analyzer

The ServerSide reports SAP released its Memory Analyzer (an Eclipse Plugin) for free. It can be downloaded from the SAP Community Network. It is only available as Windows Installer and needs at least JDK 1.5.0_07 to install (and itself doesn't run ... [More] with 1.6). Though only a 32-Bit Windows Installer is available, it still also runs on other plattforms. For installation on Linux use the following: unzip -j SAPMemoryAnalyzer.exe InstallerData/Disk1/InstData/Resource1.zip unzip -j Resource1.zip \$DIGGER_ZIP_DIRECTORY\$/MemoryAnalyzer.zip rm Resource1.zip The MemoryAnalyzer.zip contains the Eclipse Plugin and a sample HPROF file for testing it. I tested it with Eclipse 3.2 on Linux and parsed a big heap dump with it. The memory consumption is a lot less then the YourKit Profiler. Below is a screenshot of it in action. Fig 1. SAP Memory Analyzer Regarding my blog entry concerning offline analysis it can be used as alternative for the commercial Yourkit Profiler. The Calculate Retained Size is a quite useful option for finding memleaks or just caches which consume too much memory. You just click on the class and then calculate the retained size like I've done for the highlighted entry in the screenshot above. You have to find the possible hotspots yourself though whereas the Calculate Big Objects option in the YourKit Profiler does this for you. [Less]

The ServerSide reports SAP released its Memory Analyzer (an Eclipse Plugin) for free. It can be downloaded from the SAP Community Network. It is only available as Windows Installer and needs at least JDK 1.5.0_07 to install (and itself doesn't run ... [More] with 1.6). Though only a 32-Bit Windows Installer is available, it still also runs on other plattforms. For installation on Linux use the following: unzip -j SAPMemoryAnalyzer.exe InstallerData/Disk1/InstData/Resource1.zip unzip -j Resource1.zip \$DIGGER_ZIP_DIRECTORY\$/MemoryAnalyzer.zip rm Resource1.zip The MemoryAnalyzer.zip contains the Eclipse Plugin and a sample HPROF file for testing it. I tested it with Eclipse 3.2 on Linux and parsed a big heap dump with it. The memory consumption is a lot less then the YourKit Profiler. Below is a screenshot of it in action. Fig 1. SAP Memory Analyzer Regarding my blog entry concerning offline analysis it can be used as alternative for the commercial Yourkit Profiler. The Calculate Retained Size is a quite useful option for finding memleaks or just caches which consume too much memory. You just click on the class and then calculate the retained size like I've done for the highlighted entry in the screenshot above. You have to find the possible hotspots yourself though whereas the Calculate Big Objects option in the YourKit Profiler does this for you. [Less]

The ServerSide reports SAP released its Memory Analyzer (an Eclipse Plugin) for free. It can be downloaded from the SAP Community Network. It is only available as Windows Installer and needs at least JDK 1.5.0_07 to install (and itself doesn't run ... [More] with 1.6). Though only a 32-Bit Windows Installer is available, it still also runs on other plattforms. For installation on Linux use the following: unzip -j SAPMemoryAnalyzer.exe InstallerData/Disk1/InstData/Resource1.zip unzip -j Resource1.zip \$DIGGER_ZIP_DIRECTORY\$/MemoryAnalyzer.zip rm Resource1.zip The MemoryAnalyzer.zip contains the Eclipse Plugin and a sample HPROF file for testing it. I tested it with Eclipse 3.2 on Linux and parsed a big heap dump with it. The memory consumption is a lot less then the YourKit Profiler. Below is a screenshot of it in action. Fig 1. SAP Memory Analyzer Regarding my blog entry concerning offline analysis it can be used as alternative for the commercial Yourkit Profiler. The Calculate Retained Size is a quite useful option for finding memleaks or just caches which consume too much memory. You just click on the class and then calculate the retained size like I've done for the highlighted entry in the screenshot above. You have to find the possible hotspots yourself though whereas the Calculate Big Objects option in the YourKit Profiler does this for you. [Less]

Starting with Sun's JDK 1.5 it is quite easy to get information about a badly behaving application in a production environment using the JVM tools jmap and jstack. Jmap fetches a heap dump from the VM the application is running in and jstack fetches ... [More] the thread dumps. These information can be taken from the server the application server is running on and analyzed offline. Even without remote access to the server you still can get these dumps from your customer. Many Monitoring tools usually need some kind of remote access. Imagine a customer's web application with a lot of concurrent users accessing the system and the system is under heavy load. The system is only accessed during office hours. But you have noticed the load of the system stays high in the night although nobody is accessing it. What can you do? Dumping Information about running threads First of all you can fetch several thread dumps either using jstack or using kill -QUIT if you're using an older VM than 1.5. Using these dumps you can easily detect long running (looping?) threads which might cause the load. You should fetch about five dumps and wait several seconds between fetching, lets say 20 seconds. The command line with jstack then looks something like this jstack <pid> > dump.log for the first dump and jstack >> dump.log for the additional dumps. You then can use tools like the TDA - Thread Dump Analyzer to analyze the thread dumps to get an idea what is currently happening in your application. TDA will try to give you some hints about what might be wrong in the dumps (e.g. a lot of threads are waiting for the garbage collector) like in the screenshot below. Fig 1. TDA giving hints about selected dump High load without anybody accessing the application usually either means the garbage collector is running endlessly because the application is very low on memory and the garbage collector is unable to free enough memory (TDA will give you a hint on this) or there are some threads (or just one) looping and running endlessly. TDA tries to filter out all idle threads to make it easier for you to find really running threads which are either running or are waiting for some external resources (it will give you a hint regarding the last issue). You need to enable these filters in the filter settings. You might also have a look at the TDA help for additional information. For letting TDA search for long running threads mark the threads dumps you want to analyze and choose the "Find long running" threads option. TDA will then search for threads it finds in the dumps at least n-times, whereas you define n in the setting dialog for the detection. It will then present the result added to the dump tree. You should enable the idle-threads filter to filter out unimportant threads. In the screenshot below you can see a long running thread which is running in an endless loop. Fig 2. Long runinng threads detection Long running thread detection on Solaris If your application is running on Solaris and you have remote access to the machine you can even determine directly the thread which might be looping by using prstat -p <app-server-vm-pid>. prstat will show you all threads running in your application and how much CPU time each of them is consuming. The pids shown there (in decimal) can be matched to the nids (in hexadecimal) in the thread dumps. Analyzing the heap profile I use the YourKit Profiler (commercial but free eval-license for 15 days) to analyze the heap profiles. The tool has the quite handy "Find big objects" option which makes it very easy to find stuff which consumes a lot of memory and shouldn't be there or at least not that big. If you don't want to spend the money though, you can use the JVM tool jhat which starts a small web server, where you can connect to and analyze the heap profile. For a small overview you can also use the class histogram feature of the TDA tool. Use either jstack to fetch a class histogram from your application VM or use the VM-option -XX: PrintClassHistogram to have it dumped when requesting a thread dump if you are on an 1.4.x VM. Refer to the TDA help for further information [Less]

Starting with Sun's JDK 1.5 it is quite easy to get information about a badly behaving application in a production environment using the JVM tools jmap and jstack. Jmap fetches a heap dump from the VM the application is running in and jstack fetches ... [More] the thread dumps. These information can be taken from the server the application server is running on and analyzed offline. Even without remote access to the server you still can get these dumps from your customer. Many Monitoring tools usually need some kind of remote access. Imagine a customer's web application with a lot of concurrent users accessing the system and the system is under heavy load. The system is only accessed during office hours. But you have noticed the load of the system stays high in the night although nobody is accessing it. What can you do? Dumping Information about running threads First of all you can fetch several thread dumps either using jstack or using kill -QUIT if you're using an older VM than 1.5. Using these dumps you can easily detect long running (looping?) threads which might cause the load. You should fetch about five dumps and wait several seconds between fetching, lets say 20 seconds. The command line with jstack then looks something like this jstack > dump.log for the first dump and jstack for the additional dumps. You then can use tools like the TDA - Thread Dump Analyzer to analyze the thread dumps to get an idea what is currently happening in your application. TDA will try to give you some hints about what might be wrong in the dumps (e.g. a lot of threads are waiting for the garbage collector) like in the screenshot below. Fig 1. TDA giving hints about selected dump High load without anybody accessing the application usually either means the garbage collector is running endlessly because the application is very low on memory and the garbage collector is unable to free enough memory (TDA will give you a hint on this) or there are some threads (or just one) looping and running endlessly. TDA tries to filter out all idle threads to make it easier for you to find really running threads which are either running or are waiting for some external resources (it will give you a hint regarding the last issue). You need to enable these filters in the filter settings. You might also have a look at the TDA help for additional information. For letting TDA search for long running threads mark the threads dumps you want to analyze and choose the "Find long running" threads option. TDA will then search for threads it finds in the dumps at least n-times, whereas you define n in the setting dialog for the detection. It will then present the result added to the dump tree. You should enable the idle-threads filter to filter out unimportant threads. In the screenshot below you can see a long running thread which is running in an endless loop. Fig 2. Long runinng threads detection Long running thread detection on Solaris If your application is running on Solaris and you have remote access to the machine you can even determine directly the thread which might be looping by using prstat -p . prstat will show you all threads running in your application and how much CPU time each of them is consuming. The pids shown there (in decimal) can be matched to the nids (in hexadecimal) in the thread dumps. Analyzing the heap profile I use the YourKit Profiler (commercial but free eval-license for 15 days) to analyze the heap profiles. The tool has the quite handy "Find big objects" option which makes it very easy to find stuff which consumes a lot of memory and shouldn't be there or at least not that big. If you don't want to spend the money though, you can use the JVM tool jhat which starts a small web server, where you can connect to and analyze the heap profile. For a small overview you can also use the class histogram feature of the TDA tool. Use either jstack to fetch a class histogram from your application VM or use the VM-option -XX:+PrintClassHistogram to have it dumped when requesting a thread dump if you are on an 1.4.x VM. Refer to the TDA help for further information [Less]

Starting with Sun's JDK 1.5 it is quite easy to get information about a badly behaving application in a production environment using the JVM tools jmap and jstack. Jmap fetches a heap dump from the VM the application is running in and jstack fetches ... [More] the thread dumps. These information can be taken from the server the application server is running on and analyzed offline. Even without remote access to the server you still can get these dumps from your customer. Many Monitoring tools usually need some kind of remote access. Imagine a customer's web application with a lot of concurrent users accessing the system and the system is under heavy load. The system is only accessed during office hours. But you have noticed the load of the system stays high in the night although nobody is accessing it. What can you do? Dumping Information about running threads First of all you can fetch several thread dumps either using jstack or using kill -QUIT if you're using an older VM than 1.5. Using these dumps you can easily detect long running (looping?) threads which might cause the load. You should fetch about five dumps and wait several seconds between fetching, lets say 20 seconds. The command line with jstack then looks something like this jstack <pid> > dump.log for the first dump and jstack >> dump.log for the additional dumps. You then can use tools like the TDA - Thread Dump Analyzer to analyze the thread dumps to get an idea what is currently happening in your application. TDA will try to give you some hints about what might be wrong in the dumps (e.g. a lot of threads are waiting for the garbage collector) like in the screenshot below. Fig 1. TDA giving hints about selected dump High load without anybody accessing the application usually either means the garbage collector is running endlessly because the application is very low on memory and the garbage collector is unable to free enough memory (TDA will give you a hint on this) or there are some threads (or just one) looping and running endlessly. TDA tries to filter out all idle threads to make it easier for you to find really running threads which are either running or are waiting for some external resources (it will give you a hint regarding the last issue). You need to enable these filters in the filter settings. You might also have a look at the TDA help for additional information. For letting TDA search for long running threads mark the threads dumps you want to analyze and choose the "Find long running" threads option. TDA will then search for threads it finds in the dumps at least n-times, whereas you define n in the setting dialog for the detection. It will then present the result added to the dump tree. You should enable the idle-threads filter to filter out unimportant threads. In the screenshot below you can see a long running thread which is running in an endless loop. Fig 2. Long runinng threads detection Long running thread detection on Solaris If your application is running on Solaris and you have remote access to the machine you can even determine directly the thread which might be looping by using prstat -p <app-server-vm-pid>. prstat will show you all threads running in your application and how much CPU time each of them is consuming. The pids shown there (in decimal) can be matched to the nids (in hexadecimal) in the thread dumps. Analyzing the heap profile I use the YourKit Profiler (commercial but free eval-license for 15 days) to analyze the heap profiles. The tool has the quite handy "Find big objects" option which makes it very easy to find stuff which consumes a lot of memory and shouldn't be there or at least not that big. If you don't want to spend the money though, you can use the JVM tool jhat which starts a small web server, where you can connect to and analyze the heap profile. For a small overview you can also use the class histogram feature of the TDA tool. Use either jstack to fetch a class histogram from your application VM or use the VM-option -XX:+PrintClassHistogram to have it dumped when requesting a thread dump if you are on an 1.4.x VM. Refer to the TDA help for further information [Less]

This release includes: Improved Dump navigation. Added context sensitive information about dumps. Added jstack support. Refactored Monitor-Display (threads now are only displayed once). Bugfixing. Java Webstart is available here and downloadable zip is available here.

This release includes: Improved Dump navigation. Added context sensitive information about dumps. Added jstack support. Refactored Monitor-Display (threads now are only displayed once). Bugfixing. Java Webstart is available here and downloadable zip is available here.

Version 1.2 of my little tool TDA - Thread Dump Analyzer has been released, new features are: Ability to filter the threads display to be able to ignore e.g. idle threads. Improved gui layout for better navigation (three pane view instead of ... [More] two). Added 1.5 and 1.6 parsing of thread dumps. Opened Logfiles can be closed now. Reworked help. Links in help now open in external browser. Added Forum link to help menu. Improved GUI with better native Integration. Added Webstart Deployment for easy installation. Some font hacks to use GTK as native L&F on Linux and JDK 1.6 Bugfixes. You can check it out at java.net. To try it with Java Webstart (best experience if you have installed JDK/JRE 1.6) click here. The Thread Dump Analyzer can be used to analyze thread dumps obtained from production environments to analyze the application offline. Requesting a thread dump from a VM only has a very low impact on the VM, it just blocks it for a few seconds. [Less]

Version 1.2 of my little tool TDA - Thread Dump Analyzer has been released, new features are: Ability to filter the threads display to be able to ignore e.g. idle threads. Improved gui layout for better navigation (three pane view instead of two). ... [More] Added 1.5 and 1.6 parsing of thread dumps. Opened Logfiles can be closed now. Reworked help. Links in help now open in external browser. Added Forum link to help menu. Improved GUI with better native Integration. Added Webstart Deployment for easy installation. Some font hacks to use GTK as native L&F on Linux and JDK 1.6 Bugfixes. You can check it out at java.net. To try it with Java Webstart (best experience if you have installed JDK/JRE 1.6) click here. The Thread Dump Analyzer can be used to analyze thread dumps obtained from production environments to analyze the application offline. Requesting a thread dump from a VM only has a very low impact on the VM, it just blocks it for a few seconds. [Less]