Memory analysis

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 determining their root cause.

Goal of this tutorial

To review the memory analysis process. Analyze your memory whether you have problems or not. You can save a lot CPU and memory with less garbage collection.


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. Click the Install System Profile link in the easyTravel configuration UI to install the easyTravel System Profile.

Detailed steps

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 tutorial for more information.

  1. In the AppMon Client, select the System Profile for which you want to do memory analysis.
  2. Click Open Start Center > Memory Diagnosis.
  3. Under Analyze Memory Usage, click the Open memory analysis dashboard text link. The Memory Analysis dashboard opens and displays easyTravel's memory usage trends.

Memory usage

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.

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.

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.

  1. Click Open Start Center > Memory Diagnosis > Pinpoint Memory Leaks and click the Analyze Memory text link. The Total Memory dashlet appears.

  2. Click Create Memory Sanpshot, then select Deep Memory Leak Analysis in the Create Memory Snapshot dialog box. To find a memory leak, or something else that consumes memory, but is not load dependent, select the Force Garbager Collection before creating snapshot check box (selected by default). If an application does not perform optimally and does not garbage collect properly, clear the check box.

  3. Click OK.

Once the snapshot completes processing, it displays as an entry in the Total Memory dashlet.

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%.

  1. Right-click the Hot Spot.
  2. Choose the Keep Alive set. Check to see who holds this object.
  3. 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.


Memory analysis is very important if you want your application to perform and scale. Use AppMon to accomplish this.