Thread dump linux process

Thread dump linux process

Java Mission Control (JMC) is a Profiling, Monitoring, and Diagnostics Tools Suite. Java Mission Control is a tool for production time profiling and diagnostics for the HotSpot JVM. The two main features of Java Mission Control are the Management Console and Java Flight Recorder, but several more features are offered as plug-ins, which can be downloaded from the tool.

JMC tool is present in JDK_HOME\bin\jmc, Once you launch the tool, you will see all the Java processes that are running on your local host. JMC uses JVM’s Flight Recorder option to generate thread dumps, which means on your JVM flight recorder option should be enabled with following jvm arguments:

-XX:+UnlockCommercialFeatures -XX:FlightRecorder.

Prior to JDK 8u40 release, the JVM must also have been started with these flags. Since the JDK 8u40 release, the Java Flight Recorder can be enabled during runtime.

As shown in above image, you can choose the different interval time for generating thread dump. Once thread dumps are generated, you can navigate to thread dump pan, to view the generated list of thread dumps.

6. JCMD

The jcmd utility comes with the JDK and is present inside the JAVA_HOME/bin. It is used to send diagnostic command requests to the JVM, where these requests are useful for controlling Java Flight Recordings, troubleshoot, and diagnose JVM and Java Applications. It must be used on the same machine where the JVM is running, and have the same effective user and group identifiers that were used to launch the JVM.

This utility can help us in getting many details about the JVM process. To print all threads with stack traces using Thread.Print

Example: Classes taking the most memory are listed at the top, and classes are listed in a descending order.

jcmd 8845 Thread.print > ~/threadDumps.txt

7. ThreadMXBean

ThreadMXBean is an interface and belongs to java.lang.Management package. It helps to detect the threads which have entered into deadlock condition and also helps in retrieving details about them. ThreadMXBean is an interface, to get an instance of ThreadMXBean use getThreadMXBean() method of ManagementFactory.

Share this:

Источник

JStack – Java Thread Dump Analyzer

A thread dump is a list of all the Java threads that are currently active in a Java Virtual Machine (JVM). There are several ways to take thread dumps from a JVM. It is highly recommended to take more than 1 thread dump while analyzing any problem such as deadlock or resource usage analysis. It is always better to confirm in more than one thread dump than make conclusions in a single attempt.

1. Get PID of a Java Process

The first piece of information you will need to be able to obtain a thread dump is your java process’s PID.

The java JDK ships with the jps command which lists all java process ids. You can run this command like this:

Remember – you may have to run this command as $ sudo -u jps -l, where “user” is the username of the user that the java process is running as.

Even now, if you are not able to find out process id, use the below command:

2. Request a Thread Dump from JVM

If installed/available, we recommend using the jstack tool. It prints thread dumps to the command line console.

To obtain a thread dump using jstack, run the following command:

You can output consecutive thread dumps to a file by using the console output redirect/append directive:

1. The jstack tool is available since JDK 1.5.
2. jstack works even if the -Xrs JVM parameter is enabled.
3. It’s not possible to use the jstack tool from JDK 1.6 to take thread dumps from a process running on JDK 1.5.

3. Script to Collect Thread Dumps at Fixed Intervals

This simple shell script takes several jstack snapshots in fixed time intervals: [Reference document]

#!/bin/bash if [ $# -eq 0 ]; then echo >= 2 "Usage: jstackSeries [ count [ delay ] ]" echo >= 2 " Defaults: count = 10, delay = 1 (seconds)" exit 1 fi pid=$1 # required count=$ # defaults to 10 times delay=$ # defaults to 1 second while [ $count -gt 0 ] do jstack $pid >jstack.$pid.$(date +%H%M%S.%N) sleep $delay let count-- echo -n "." done

Use the above script like this:

$ jstackSeries 10 5

4. Compare Two Thread Dumps

To compare thread dumps, you may use interactive difference viewers, e.g.

$ vimdiff file1 file2 file3 file4 # up to 4 files

Another way to see what parts of the jstack trace are changing over time is to compare adjacent jstack trace using $ context diff (-c option):

d_old="" for d in jstack.13585.12171* do if [ -n "$d_old" ] then diff -c "$d_old" "$d" fi d_old="$d" done

Here, the result shows only the places where the JStack thread dump changes from file to file.

Источник

kill -3 to get java thread dump

I am using kill -3 command to see the JVM’s thread dump in unix. But where can I find the output of this kill command? I am lost!!

Which process are you killing? Is it a J2EE app server? If it’s the case you should find the stack trace in the standard out.

In my case (a Spring Boot application running on CentOS 7), the thread dump was logged to /var/log/messages .

10 Answers 10

You could alternatively use jstack (Included with JDK) to take a thread dump and write the output wherever you want. Is that not available in a unix environment?

Yes — at the point in time it is run. You can also specify -l (lowercase L) for a long listing that prints additional lock information

Until the jstack command fails consistently due to «Unable to deduce type of thread from address» ;-(

If you’re seeing that error, I suggest taking it up with your vendor. A quick search shows, for example, there is an open bug in RHEL regarding this error and openjdk.

It’s worth noting that jstack requires the JDK. If you’re running apps on a server that only has the JRE installed, you’ll need to find another means for thread dumping.

Here is how to use jstack to obtain thread dump of a process running under different user, like windows service: stackoverflow.com/questions/1197912/…

The thread dump is written to the system out of the VM on which you executed the kill -3 . If you are redirecting the console output of the JVM to a file, the thread dump will be in that file. If the JVM is running in an open console, then the thread dump will be displayed in its console.

There is a way to redirect JVM thread dump output on break signal to separate file with LogVMOutput diagnostic option:

-XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=jvm.log 

Technically this doesn’t «redirect» the thread dump output. It turns on JVM logging into jvm.log (which includes thread dump output) but kill -QUIT will still dump to the process’s stdout (aswell). Upvoted for the description of obscure JVM options 🙂

With Java 8 in picture, jcmd is the preferred approach.

Following is the snippet from Oracle documentation :

The release of JDK 8 introduced Java Mission Control, Java Flight Recorder, and jcmd utility for diagnosing problems with JVM and Java applications. It is suggested to use the latest utility, jcmd instead of the previous jstack utility for enhanced diagnostics and reduced performance overhead.

However, shipping this with the application may be licensing implications which I am not sure.

Unfortunately jcmd fails to connect to windows service process with com.sun.tools.attach.AttachNotSupportedException: Insufficient memory or insufficient privileges to attach while jstack -F succeeds: stackoverflow.com/questions/1197912/…

You need to run jcmd Thread.dump under the same user as java process has, otherwise your connections will be dropped. See stackoverflow.com/questions/25438983/…

In the same location where the JVM’s stdout is placed. If you have a Tomcat server, this will be the catalina_(date).out file.

When using kill -3 one should see the thread dump in the standard output. Most of the application servers write the standard output to a separate file. You should find it there when using kill -3. There are multiple ways of getting thread dumps:

• kill -3 : Gives output to standard output.
• If one has access to the console window where server is running, one can use Ctrl + Break combination of keys to generate the stack trace on STDOUT.
• For hotspot VM’s we can also use jstack command to generate a thread dump. It’s a part of the JDK. Syntax is as follows:

Usage: jstack [-l] (to connect to running process) jstack -F [-m] [-l] (to connect to a hung process) - For JRockit JVM we can use JRCMD command which comes with JDK Syntax: jrcmd [ []] [-l] [-f file] [-p] -h] 

Источник

Generating a Thread Dump Externally

If Confluence stops responding and you can’t create a thread dump within Confluence, you can create thread dumps outside the application. External thread dumps are also useful if you require information on locks being held or waited upon by threads.

Take Multiple Thread Dumps

Typically you’ll want to take several dumps about 10 seconds apart, in which case you can generate several dumps and output the stack traces to a single file.

On this page:

Generating thread dumps using the Performance Data Collector

The Performance Data Collector is a server-side, standalone application that exposes a number of REST APIs for collecting performance data. It can be used to collect data, such as thread dumps, disk speed and CPU usage information, to troubleshoot performance problems.

Generating thread dumps on Linux

To generate a thread dump on Linux (or Solaris or other Unixes):

Identify the java process that Confluence is running in.: This can be achieved by running a command similar to:

Generating thread dumps on windows

Generating a thread dump from the console

If you are not running Confluence as a service, you can generate a thread dump directly in the console.

Click the console window and press +BREAK (or SHIFT+CTRL+PAUSE on some keyboards). The thread dump will print directly to the console.

Generating a thread dump using jstack

The JDK (Java Development Kit) includes jstack, which is used for generating thread dumps.

Note: The JRE (Java Runtime Environment) that is bundled with the Confluence installer does not include jstack. You’ll need to have the full JDK installed.

To generate a thread dump using jstack:

1. Identify the process. Launch the task manager by, pressing Ctrl + Shift + Esc and find the Process ID of the Java (Confluence) process. (If you can’t see the PID column right click a column heading in Task Manager and choose PID).
2. Run jstack to Capture a Single Thread Dump. This command will take one thread dump of the process id , in this case the pid is 22668:

adam@track:~$ jstack 22668 > threaddump.txt 

Common issues with jstack:

• You must run jstack as the same user that is running Confluence
• If the jstack executable is not in your $PATH, then please look for it in your /bin directory
• If you receive java.lang.NoClassDefFoundError: sun/tools/jstack/JStack check that tools.jar is present in your JDK’s lib directory. If it is not, download a full version of the JDK.
• If you see the following message: ‘Not enough storage is available to process this command , ‘ see this article.
• If you get the error «Not enough storage is available to process this command», download the ‘psexec’ utility from here, then run the following command using:
  psexec -s jstack >> threaddumps.txt

Output

Thread dumps appear in the catalina.out file in the application directory’s logs folder. Search for «thread dump» in the log file for the beginning of the dump.

Often Support may ask you to generate a sequence of thread dumps over a short period, so that they can compare what each dump contains and to look for any long running threads that could be the cause of the performance issue.

You can manually generate multiple thread dumps by executing the command repeatedly, but it is often easier to use a small script to automate the process. Here’s an example that you can adapt to run on your Linux server:

 for i in `seq 1 10` ; do echo $ your/path/to/jstack `ps aux | grep java | grep confluence | grep -v grep | awk ''` >> threaddump.log sleep 10 done

Thread dump analysis tools

Источник