Troubleshooting: How to diagnose a memory leak

Official Content

A memory leak occurs when the program fails to release memory that's no longer needed. Note that the following article provides an explanation for anyone working specifically with Java only

The symptom is a progressive deterioration of the application's response, until it remains unresponsive or falls down.
The tools / techniques which can be used to detect a memory leak in a GeneXus application could be:

1. Monitor the memory use of the application, by using Jconsole or other monitors:

Jconsole graphs give an idea of a possible memory leak. When the garbage collector runs, the memory which isn't used any more is freed. If a memory leak exists, the garbage collector (GC) doesn't free that memory because it keeps it as being used through all the lifetime of the program. So, in the memory usage graphs when memory is freed by running the GC, it is lowered to a certain point but it isn't freed entirely, and as times passes, the leak is more apparent.

See also Monitoring Memory Management with JMX

2. Using diagnosis tools

In order to know which classes have the memory leak problem, you should use an-other diagnosis tool, such as:

HPROF dumps
1. Hpjmeter: diagnose performance problems
2. How to read logs generated by hprof without graphical tools
3. Jhat: After generating hprof dump with binary format (format=b) it can be analyzed using Jhat

Dump on error: The -XX:+HeapDumpOnOutOfMemoryError command-line option tells the HotSpot VM to generate a heap dump when an allocation from the Java heap or the permanent generation cannot be satisfied.http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/clopts.html
The resulting dump is binary, and can be read using Jhat.

Class Loading Dumps:+TraceClassLoading -XX:+TraceClassUnloading

3. Verifying the Garbage Collector configuration

Sometimes, the Garbage Collector's behavior has an influence and it should be tuned in order to adjust the time response of the application. The garbage collection, just like any other process, has a processing cost and can be tuned according to the resources of the server (the process can be executed in parallel).

By default, the GC executes minor collections in sequence, taking unused memory from the Eden space to the Survival space and from there to the Tenured (old) space. In general, these collections take little execution time. The greatest collection is the Full collection, which takes place when the unused memory of the old gen space is released. By default, it waits for the old gen space to be full to run the Full GC. 


This behavior can be changed with JVM parameters, by causing the GC to be executed when the memory ratio between the Old gen space and Survival is lowest. By default, the JVM grows or shrinks the heap at each collection to try to keep the proportion of free space to living objects at each collection within a specific range.
This target range is set as a percentage by the parameters -XX:MinHeapFreeRatio=<minimum> and -XX:MaxHeapFreeRatio=<maximum>,  and the total size is bound below by -Xms and above by -Xmx.

This should be examined on a case-by-case basis, as you should take into account that running more Full GC can have a negative effect.
In sum, given that the Full GC is run by default when the old gen space memory is full, the idea is to reduce the collection's running time, taking advantage of the server's resources. For a 2-processor server, you can run the GC in parallel with the application, and for the VM to benefit from that advantage, you should indicate certain parameters: 
 -XX:UseParNewGC y -XX:UseConcMarkSweepGC

References:


http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html 
http://www.petefreitag.com/articles/gctuning/
https://java.sun.com/j2se/reference/whitepapers/memorymanagement_whitepaper.pdf

Tip

Execute the application with the options: -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails, in order to get the necessary informattion about the time spent by the GC when it runs.

Other links in the community wiki

JMX management using Tomcat and MC4J
JMX management using OAS and MC4J
Using The Thread Tab with JConsole

Detailed information about memory issues

Virtual Machine ergonomics to understand how the virtual machine is auto configured based on the platform configuration.
Memory basics to understand the kinds of memory created and used by the Garbage Collector.
Memory pools to check the memory pools available depending on the Java Virtual Machine being used.
Garbage Collector basics with a basic introduction to the Garbage Collector and memory assignment to understand how the memory is assigned.
Java HotSpot VM options for typical command-line options and environment variables that can affect the performance characteristics of the Java HotSpot Virtual Machine.



Was this page helpful?
What Is This?
Your feedback about this content is important. Let us know what you think.