Memory thrash is caused when a large number of temporary objects are created in very short intervals. Although these objects are temporary and are eventually cleaned up, the garbage collection mechanism may struggle to keep up with the rate of object creation. This may cause application performance problems. Monitoring the time spent in garbage collection can provide insight into performance issues, including memory thrash.
For example, an increase in the number of spikes for major collections either slows down a JVM or indicates potential memory thrash. Use object instance tracking to isolate the root cause of the memory thrash. To configure and enable object instance tracking, see Object Instance Tracking for Java.
AppDynamics automatically tracks object instances for the top 20 core Java (system) classes and the top 20 application classes.
The Object Instance Tracking subtab provides the number of instances for a particular class and graphs the count trend of those object in the JVM. It provides the shallow memory size (the memory footprint of the object and the primitives it contains) used by all the instances.
Analyzing Memory Thrash
Once a memory thrash problem is identified in a particular collection, start the diagnostic session by drilling down into the suspected problematic class.
Select the class name to monitor and click Drill Down at the top of the Object Instance Tracking dashboard or right-click the class name and select the Drill Down option.
After the drill down action is triggered, data collection for object instances is performed every minute. This data collection is considered to be a diagnostic session and the Object Instance Tracking dashboard for that class is updated with this icon
The Object Instance Tracking dashboard indicates possible cases of memory thrash. Prime indicators of memory thrash problems indicated on the Object Instance Tracking dashboard are:
- Current Instance Count: A high number indicates the possible allocation of a large number of temporary objects.
- Shallow Size: Is the approximate memory used by all instances in a class. A large number for shallow size signals potential memory thrash.
- Instance Count Trend: A saw wave is an instant indication of memory thrash.
If you suspect you have a memory thrash problem at this point, then you should verify that this is the case. See To verify memory thrash.
Verify Memory Thrash
Select the class name to monitor and click Drill Down at the top of the Object Instance Tracking dashboard. On the Object Instance Tracking window, click Show Major Garbage Collections.
The following Object Instance Tracking Overview provides further evidence of a memory thrash problem.
If the instance count doesn’t vary with the garbage collection cycle, it is an indication of a potential leak and not a memory thrash problem. See Java Memory Leaks.
Troubleshooting Java Memory Thrash Using Allocation Tracking
Allocation Tracking tracks all the code paths and those business transactions that are allocating instances of a particular class. It detects those code path/business transactions that are creating and throwing away instances.
To use allocation tracking
- Using the Drill Down option, trigger a diagnostic session.
- Click the Allocation Tracking tab.
- Click Start Allocation Tracking Session to start tracking code paths and business transactions.
- Enter the session duration and allow at least 1 to 2 minutes for data generation.
- Click Refresh to retrieve the session data.
- Click on a session to view its details.
- Use the Information presented in the Code Paths and Business Transaction panels to identify the origin of the memory thrash problem.
Monitor Java Object Instances
If the application uses a JRE (rather than a JDK), the following steps enabled object instance tracking:
- Ensure the tools.jar file is in the
- On the Node Dashboard, click the Memory tab.
- On the Memory tab, click the Object Instance Tracking subtab.
- Click On and then OK.