The following troubleshooting guidelines can help you to determine the root cause of many Java-related issues

Step 1. CPU saturated?

Is the CPU of the JVM saturated?

How do I know? 

  1. Display the Tier Flow Map.
  2. Click the Nodes tab, and then show Hardware data.
  3. Sort by CPU % (current).

If the CPU % is 90 or higher, the answer to this question is Yes. Otherwise, the answer is No.

Yes – Go to Step 2.

No – The issue is probably related to a custom implementation your organization has developed. Take snapshots of the affected tier or node(s) and work with internal developers to resolve the issue.

Step 2. Significant garbage collection activity?

Is there significant garbage collection activity? 

How do I know? 

  1. Display the Tier Flow Map.
  2. Click the Nodes tab, and then click the Memory tab.
  3. Sort by GC Time Spent to see how many milliseconds per minute is being spent on GC; 60,000 indicates 100%.
  4. If GC Time Spent is higher than 500 ms, the answer to the question in Step 5 is Yes. Otherwise, the answer is No.

Result

Yes – Go to Step 3.

No – Go to Step 4.

Step 3. Memory leak?

Is there a memory leak?

How do I know?

  1. From the list of nodes displayed in the previous step (when you were checking for Garbage Collecting activity), double-click a node that is experiencing significant GC activity.
  2. Click the Memory tab, then scroll down to display the Memory Pool graphs at the bottom of the window.
  3. Double-click the Old Gen memory pools chart.
     

If memory is not being released (use is trending upward), the answer to this question is Yes. Otherwise, the answer is No.

Result

Yes – Use various AppDynamics features to track down the leak. One useful tool for diagnosing a memory leak is object instance tracking, which lets you track objects you are creating and determine why they aren't being released as needed. Using object instance tracking, you can pinpoint exactly where in the code the leak is occurring. For instructions on configuring object instance tracking, as well as links to other tools for finding and fixing memory leaks, see Need more help? below.

No – Increase the size of the JVM. If there is significant GC activity but there isn't a memory leak, then you probably aren't configuring a large enough heap size for the activities the code is performing. Increasing the available memory should resolve your problem.

Whether you answered Yes or No, you have isolated the problem.

Step 4. Resource leak?

Is there a resource leak?

How do I know? 

  1. In the left Navigation pane, go to (for example) Metric Browser > Application Infrastructure Performance > TierName > Individual Nodes > NodeName > JMX > JDBC Connection Pools > PoolName.
  2. Add the Active Connections and Maximum Connections metrics to the graph.
  3. Repeat as needed for various pools your application is using.

If connections are not being released (use is trending upward), the answer to the question in Step 7 is Yes. Otherwise, the answer is No.

Result

Yes – To determine where in your code resources are being created but not being released as needed, take a few thread dumps using standard commands on the problematic node. You can also create a diagnostic action within AppDynamics to create a thread dump; see Thread Dump Actions in Diagnostic Actions.

No – Restart the JVM. If none of the above diagnostic steps addressed your issue, it's possible you're simply seeing a one-time unusual circumstance, which restarting the JVM can resolve.