Tomcat Thread Dump Guide

This techblog post explains how to capture Java thread dumps from a running Tomcat JVM at 15-second intervals. The purpose is to collect a series of snapshots during peak load of your m-Power environment, so you can identify threads, requests, database calls, or other activity that may be repeatedly stalled or consuming resources.

A thread dump does not stop or restart Tomcat. It captures a snapshot of what the JVM threads are doing at that moment while the application continues to run.

Before You Begin

The Java Development Kit (JDK) installed on the m-Power/Tomcat server must include the jcmd utility. You will run the commands that follow in this techblog via Windows Command Prompt (CMD) on the m-Power/Tomcat server.

It is best to begin capturing thread dumps shortly before or during the period when the slowdown or peak load is occurring. A single thread dump is only one snapshot. Multiple dumps taken over time are much more useful because they can show whether the same threads remain stuck in the same operation.

1. Identify the Tomcat JVM Process ID

Open Command Prompt (as administrator) and run:

jcmd

This lists running Java processes. Locate the Tomcat process and note its process ID (PID). If you cannot find your Tomcat service running the above comamnd, than you can use Windows to help identify the Tomcat service PID:

tasklist /svc | findstr /I "tomcat"

In the example below, both development (TC10DEV) and production (TC10PROD) services are found:

2. Test a Single Thread Dump

Before starting the repeating capture, test one thread dump. Replace 33380 with the actual Tomcat JVM PID:

jcmd 33380 Thread.print > "%USERPROFILE%\Desktop\tomcat-thread-dump.txt"

This will generate on the desktop a .txt file named tomcat-thread-dump.txt.

Open the generated text file and confirm that it contains a full Java thread dump.

3. Create a Folder for the Thread Dumps

Using CMD or File Explorer’s GUI, create a folder on the desktop to keep the repeated thread dumps together:

mkdir "%USERPROFILE%\Desktop\thread-dumps"

4. Capture a Thread Dump Every 15 Seconds

Replace 33380 with your actual Tomcat JVM PID, then run the following command:

jcmd 33380 Thread.print > "%USERPROFILE%\Desktop\thread-dumps\tomcat-thread-1.txt" &
timeout /t 15 /nobreak >nul &

jcmd 33380 Thread.print > "%USERPROFILE%\Desktop\thread-dumps\tomcat-thread-2.txt" &
timeout /t 15 /nobreak >nul &

jcmd 33380 Thread.print > "%USERPROFILE%\Desktop\thread-dumps\tomcat-thread-3.txt" &
timeout /t 15 /nobreak >nul &

jcmd 33380 Thread.print > "%USERPROFILE%\Desktop\thread-dumps\tomcat-thread-4.txt" 

The command will create files such as:

• tomcat-thread-1.txt
• tomcat-thread-2.txt
• tomcat-thread-3.txt
• tomcat-thread-4.txt

A new dump is captured, followed by a 15-second wait before the next capture. Leave the command running for the 1-minute period which you are investigating.

5. What to Look for in the Thread Dumps

The main value comes from comparing several dumps taken during the same period of poor performance. Look for threads that repeatedly appear in the same state and at the same point in the stack trace.

• Tomcat request threads that remain in the same application code or servlet across multiple dumps.
• Database activity where multiple request threads remain inside JDBC calls or SQL execution.
• Connection pool waits where threads repeatedly wait while attempting to borrow or obtain a database connection.
• BLOCKED threads waiting to acquire the same Java monitor or lock.
• RUNNABLE threads that repeatedly remain in the same CPU-intensive method or operation.
• WAITING or TIMED_WAITING threads that may indicate a resource wait. These states are not automatically a problem, so the stack trace and repeated behavior matter.

Alternatively, you may have the staff at mrc help you analyze the activity by reaching out to support@mrc-productivity, or specifically attaching these to your helpdesk ticket from the m-Power Customer Portal.

Why Multiple Dumps Matter

A thread that happens to be executing a SQL statement or application method in one dump may be completely normal. However, if the same thread or many Tomcat request threads remain at the same point across several dumps, that is much stronger evidence of a bottleneck.

For example, if several consecutive dumps show a large number of Tomcat executor threads waiting for database connections, the connection pool may be exhausted or database requests may be taking long enough that connections are not being returned quickly enough. If the same request threads repeatedly remain inside JDBC or a specific SQL operation, the database query or downstream database activity becomes a stronger area to investigate.

The goal is not simply to find WAITING or BLOCKED threads. The goal is to identify a repeated pattern across multiple dumps that corresponds with the time users are experiencing slow performance.