What should i do?

Hello Damianostom,

Greetings!

Inorder to accurately point the lines of code causing the CPU spike, you need to analyze not only thread dumps but also 'top -H -p {PID}' command output, where {PID} is your Java application's process Id which is experiencing CPU spike. When you issue this ‘top’ command with given arguments, it will list all the threads running in the application and amount of CPU each one of the thread consume. Once you have both the data, you can identify high CPU consuming thread and lines of code they are executing.

You can use the open source yCrash script which will capture 360-degree application level artifacts (like GC logs, 3 snapshots of thread dumps, heap dumps) and system level artifacts (like top, top -H, netstat, vmstat, iostat, dmesg, diskusage, kernel parameters...). Once you have these data, either you can manually analyze them or upload it to yCrash tool. Tool analyzes all these dataset and generates an instant root cause analysis report pointing out exact line of code causing the CPU spike. Here is more detailed information on how to diagnose high CPU spike.

Tactical approach:

fastThread tool uses its heuristics algorithms and shows the potential (but not exact) threads are consuming high cpu in the section 'CPU consuming threads'.  You want to refer to see the threads pointed in this 'CPU consuming threads' section.

In your case the report says, there are 35 threads in org.opennms.netmgt.eventd.EventIpcManagerDefaultImpl.broadcastNow, appearing to wait on responses from an external system. This isn't necessarily a problem by itself, but it’s something to look into, as delays or timeouts from the external system could impact overall performance.

You can try out these suggestions:

• Check the external system’s availability and response times.
• Review stack traces of those stuck threads to pinpoint where threads are blocked.
  
  
  
  
  
• 631 threads are in Timed Waiting state. Having such a thread count in TIMED_WAITING can also slightly increase memory overhead and may contribute to java.lang.OutOfMemoryError: Unable to create new native thread, especially if native thread limits are reached. This can also degrade application performance and responsiveness.
• You can tune thread pool sizes and connection timeouts. Consider reducing thread creation rates or using asynchronous, non-blocking processing where possible.
• Configure proper connection and read timeouts. Tune thread pool limits and consider non-blocking processing where possible. Monitor thread count and native memory to avoid exhaustion.

Review the CPU Consuming Threads section for any additional high CPU contributors.

Thanks.

Hello damianostom

There are a lot of CPU Consuming threads in the report. Hence the CPU usgage is increased. So need to revisit the code and profile where it is taking too much CPU.

Check your CPU Consuming threads section in the report