Java memory tuning tips

Java memory tuning tips

+
Search Tips | Advanced Search

Overview

Garbage collection normally consumes from 5% to 20% of total execution time of a properly functioning application. To determine the percentage of time the JVM spends in garbage collection, divide the time it took to complete the collection by the length of time since the last allocation failure and multiply the result by 100. For example,
83.29/3724.32 * 100 = 2.236 percent

Use garbage collection to evaluate application performance health. By monitoring garbage collection during the execution of a fixed workload, you gain insight as to whether the application is over-utilizing objects. Garbage collection can even detect the presence of memory leaks.
We can monitor garbage collection statistics using...

Using the verbose:gc JVM configuration setting.
Object statistics in the Tivoli Performance Viewer

Before you begin monitoring, set the minimum and maximum heap sizes to the same value.

Detect over-utilization of objects

Use TPV or IBM Support Assistant utilities to check if the application is overusing objects, by observing the counters for the JVM runtime.
To enable the Java virtual machine profiler interface (JVMPI) counters...

Set the -XrunpmiJvmpiProfiler command line option
Set the JVM module maximum level in PMI.

The optimum average time between garbage collections is at least 5-6 times the average duration of a single garbage collection. If you do not achieve this number, the application is spending more than 15% of its time in garbage collection.
To clear the garbage collection bottleneck optimize the application is to implement object caches and pools. Use a Java profiler to determine which objects to target.
If we cannot optimize the application, add...

Memory
Processors
Clones

Additional memory allows each clone to maintain a reasonable heap size. Additional processors allow the clones to run in parallel.

Detect memory leaks

Memory leaks result when garbage collection occurs more and more frequently until the heap is exhausted.
The Java code fails with a fatal Out of Memory exception.
Memory leaks occur when an unused object has references that are never freed. Memory leaks most commonly occur in collection classes, such as Hashtable because the table always has a reference to the object, even after real references are deleted.
High workload often causes applications to crash immediately after deployment in the production environment. This is especially true for leaking applications where the high workload accelerates the magnification of the leakage and a memory allocation failure occurs.
Memory leak testing measures kilobytes that cannot be garbage collected and compares these amounts between expected sizes of useful and unusable memory. This task is achieved more easily if the numbers are magnified, resulting in larger gaps and easier identification of inconsistencies.

Long-running test
Memory leak problems can manifest only after a period of time, therefore, memory leaks are found during long-running tests. Short running tests can lead to false alarms.
It is sometimes difficult to know when a memory leak is occurring in the Java language, especially when memory usage has seemingly increased either abruptly or monotonically in a given period of time. The reason it is hard to detect a memory leak is that these kinds of increases can be valid or might be the intention of the developer. We can learn how to differentiate the delayed use of objects from completely unused objects by running applications for a longer period of time. Long-running application testing gives you higher confidence for whether the delayed use of objects is actually occurring.
Repetitive test
In many cases, memory leak problems occur by successive repetitions of the same test case. The goal of memory leak testing is to establish a big gap between unusable memory and used memory in terms of their relative sizes. By repeating the same scenario over and over again, the gap is multiplied in a very progressive way. This testing helps if the number of leaks caused by the execution of a test case is so minimal that it is hardly noticeable in one run.
Use repetitive tests at the system level or module level.
The advantage with modular testing is better control. When a module is designed to keep the private module without creating external side effects such as memory usage, testing for memory leaks is easier. First, the memory usage before running the module is recorded. Then, a fixed set of test cases are run repeatedly. At the end of the test run, the current memory usage is recorded and checked for significant changes. Remember, garbage collection must be suggested when recording the actual memory usage by inserting System.gc() in the module where you want garbage collection to occur, or using a profiling tool, to force the event to occur.
Concurrency test
Some memory leak problems can occur only when there are several threads running in the application. Unfortunately, synchronization points are very susceptible to memory leaks because of the added complication in the program logic. Careless programming can lead to kept or unreleased references. The incident of memory leaks is often facilitated or accelerated by increased concurrency in the system. The most common way to increase concurrency is to increase the number of clients in the test driver.
Consider the following points when choosing which test cases to use for memory leak testing:

A good test case exercises areas of the application where objects are created. Most of the time, knowledge of the application is required. A description of the scenario can suggest creation of data spaces, such as...

Adding a new record
Creating an HTTP session
Performing a transaction and searching a record

Look at areas where collections of objects are used. Typically, memory leaks are composed of objects within the same class. Also, collection classes such as Vector and Hashtable are common places where references to objects are implicitly stored by calling corresponding insertion methods. For example, the get method of a Hashtable object does not remove its reference to the retrieved object.

Tivoli Performance Viewer can help find memory leaks. For best results, repeat experiments with increasing duration, like 1000, 2000, and 4000-page requests. The Tivoli Performance Viewer graph of used memory should have a sawtooth shape. Each drop on the graph corresponds to a garbage collection. There is a memory leak if one of the following occurs:

The amount of memory used immediately after each garbage collection increases significantly. The sawtooth pattern looks more like a staircase.
The sawtooth pattern has an irregular shape.
Also, look at the difference between the number of objects allocated and the number of objects freed. If the gap between the two increases over time, there is a memory leak.
Heap consumption indicating a possible leak during a heavy workload (the application server is consistently near 100% CPU utilization), yet appearing to recover during a subsequent lighter or near-idle workload, is an indication of heap fragmentation. Heap fragmentation can occur when the JVM can free sufficient objects to satisfy memory allocation requests during garbage collection cycles, but the JVM does not have the time to compact small free memory areas in the heap to larger contiguous spaces.
Another form of heap fragmentation occurs when small objects (less than 512 bytes) are freed. The objects are freed, but the storage is not recovered, resulting in memory fragmentation until a heap compaction has been run.
Heap fragmentation can be reduced by forcing compactions to occur, but there is a performance penalty for doing this. Use the Java -X command to see the list of memory options.

Java heap parameters

The Java heap parameters also influence the behavior of garbage collection. Increasing the heap size supports more object creation. Because a large heap takes longer to fill, the application runs longer before a garbage collection occurs. However, a larger heap also takes longer to compact and causes garbage collection to take longer.
For performance analysis, the initial and maximum heap sizes should be equal.
When tuning a production system where the working set size of the Java application is not understood, a good starting value for the initial heap size is 25% of the maximum heap size. The JVM then tries to adapt the size of the heap to the working set size of the application.

Imagine three CPU profiles, each running a fixed workload with varying Java heap settings.

In the middle profile, the initial and maximum heap sizes are set to 128MB. Four garbage collections occur. The total time in garbage collection is about 15% of the total run.
When the heap parameters are doubled to 256MB, the length of the work time increases between garbage collections. Only three garbage collections occur, but the length of each garbage collection is also increased.
In the third profile, the heap size is reduced to 64MB and exhibits the opposite effect. With a smaller heap size, both the time between garbage collections and the time for each garbage collection are shorter.

For all three configurations, the total time in garbage collection is approximately 15%.
If you expand the heap too aggressively, paging can occur. Use vmstat or Windows 2000/2003 Performance Monitor to check for paging, and, if found, reduce the size of the heap or add more memory to the system.
When all the runs are finished, compare the following statistics:

Number of garbage collection calls
Average duration of a single garbage collection call
Ratio between the length of a single garbage collection call and the average time between calls
If the application is not over-utilizing objects and has no memory leaks, the state of steady memory utilization is reached. Garbage collection also occurs less frequently and for short duration.
If the heap free space settles at 85% or more, consider decreasing the maximum heap size values because the application server and the application are under-utilizing the memory allocated for heap.

Related Tasks
Tuning the application serving environment
Performance: Resources for learning.
IBM Support

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.
Tivoli is a trademark of the IBM Corporation in the United States, other countries, or both.