What is memory analysis?
The Java memory model - or garbage collector (GC) - solves many memory problems. However, new strains of memory leaks pop up constantly. Many applications simply consume too much memory or thrash the GC.
Memory analysis is the art of identifying all these problems, and their root cause.
Goal of this walkthrough
This walkthrough reviews the of memory analysis process. Analyze your memory whether you have problems or not. You can save a lot CPU (less GC) and memory.
Use easyTravel to simulate memory problems and analyze them.
You need the following components installed and configured:
- easyTravel demo application.
- AppMon installation with a Test Center Edition license.
- Default easyTravel System Profile.
Monitor memory trend
Monitor the memory trends when you run your application with or without load. If the memory increases continuously, you should analyze this. To see a trend, activate the Medium Memory Leak Problem Pattern. See the attached session of this walkthrough for more information.
- Open the Start Center.
- Select Memory Diagnosis.
- Select the correct System Profile.
- Select Analyze Memory Usage.
The Memory Analysis dashboard opens and displays easyTravel’s memory usage trends. The Memory Leak Problem pattern displays a growing memory demand. When you monitor the memory, keep an eye on the GC behavior. High GC can lead to high CPU utilization and slow response times. This is due to suspensions. See Memory Problems on the Performance Wiki for more information.
Analyze memory trend
Memory increases for two reasons: A bad GC memory setting or an application problem. The application problem is either a memory leak or one of the several other memory problems. For more information, see Memory Problems in the Performance wiki.
If the memory is consistently high, with GCs, but no
OutOfMemory errors, analyze the constant high memory usage. Identify how GC impacts your response time. If memory increases and you get an
Out Of Memory Error, try to pinpoint memory leaks.
If memory increases slowly, and a GC decreases memory, but it increases again, check your GC/memory settings. They may be incorrect. See Understanding and Optimizing your Garbage Collector for more information.
If you have many GCs and volatile memory, but your GC settings are correct, your transactions may consume too much memory. Analyze the transaction memory usage.
Analyze constant high memory usage
Take a leak snapshot to discover why your JVM/CLR consumes too much memory. Click Start Center > Memory Diagnosis > Pinpoint Memory > Deep Leak Analysis.
To find a memory leak, or something else that consumes memory, but is not load dependent, force a GC. If an application does not perform optimally and does not GC properly, do not choose this option.
This example forces the GC. Look at the hotspot to see what holds most of the memory in the JVM. Use this view to look for memory leaks or to understand which objects keep most of the objects alive. Notice that a HashMap Segment holds 52%.
- Right-click the Hot Spot.
- Choose the Keep Alive set. Check to see who holds this object.
- Look at Follow References to see which references this object holds. This displays instances that the selected object keeps alive, and an aggregated set with instance count.
Use this to get an overview:
- The GC size tells how much free memory you would have if the objected were garbage collected.
- Follow References does not aggregate, but shows the real reference tree.
- Keep Alive only shows you what is kept alive or what keeps alive. It also aggregates views of things like instance count.
- Direct follows the object structure and displays which memory holds the reference.
Look at the HTTP sessions or duplicated strings. These can cause high memory because they keep too many things. For more information, see the Excessive Memory Usage section in Memory Problems on the Performance Wiki.
Memory analysis is very important if you want your application to perform and scale. Use AppMon to accomplish this.