A thread dump is a snapshot of all running threads in a Java process. It is an essential artifact for solving various production issues like CPU spikes, unresponsive in application, poor response time, blocked threads, high memory consumption. So, to make troubleshooting easier, we’ve seen companies capture thread dumps on a periodic basis (every 5 or 2 minutes). So we were curious to learn about the overhead of catching thread dump on a periodic basis. We therefore set out to carry out the case study below.
For our study, we chose to use open source spring start pet clinic app. Pet Clinic is a children’s app that was developed to demonstrate the functionality of the spring-loaded starter frame.
We have run this application in OpenJDK 11. We have deployed this application on the Amazon AWS t2.medium EC2 instance which has 16 GB of RAM and 2 processors. The test was orchestrated using the Apache JMeter stress testing tool. We used AWS Cloudwatch to measure CPU, memory usage. Here is a summary of the tools / technologies we used to carry out this case study:
- OpenJDK 11
- AWS EC2
- AWS Cloudwatch
- Apache JMeter
In this environment, we performed 3 tests:
- Basic test – In this scenario, we ran the pet clinic app without capturing thread dumps using the JMeter tool for 20 minutes with 200 concurrent users
- The wire discharges every 5 minutes Test – In this scenario, we ran the vet clinic app using the same JMeter script for 20 minutes with 200 concurrent users. However, we did capture the feed dump of a pet clinic app every 5 minutes.
- The wire discharges every 2 minutes Test – In this scenario, we ran the vet clinic app using the same JMeter script for 20 minutes with 200 concurrent users. However, we captured the feed dump of a pet clinic app every 2 minutes.
To note: If you don’t know how to capture a thread dump, see How to capture thread dumps? 8 choices for more details.
We captured the average CPU and memory usage from AWS Cloudwatch and the average response time and throughput of the JMeter tool. The data collected from all test cases is summarized in the table below.
|Data collected||Basic test||Every 5 minutes test||Every 2 minutes test|
|Average CPU Usage||8.35%||10.40%||7.92%|
|Average memory usage||20.80%||19.90%||19.60%|
|Average response time||3901 ms||3888 ms||3770 ms|
|Average flow||24.4 / s||25.8 / s||24.8 / s|
As you can see, there is no noticeable difference in CPU and memory consumption. Likewise, there is no noticeable difference in average response and transaction throughput.
So, based on our study, we can conclude that there is no noticeable overhead in capturing thread dumps over a 5 or 2 minute interval.