Java heap parameters

The Java heap parameters also influence the behavior of garbage collection. Increasing the heap size allows more objects to be created. 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, as this will eliminate heap growing and shrinking delays. Equating initial with maximum heapsize without previous heap size tuning will in most cases create an inefficiently used heap: when it is sized too big, the heap is not used by the application entirely and thus memory resources are wasted.

When tuning a production system where the working set size of the Java application is not understood, a good starting value is to let the initial heap size be 25% of the maximum heap size. The JVM will then try to adapt the size of the heap to the working set size of the application.

Run a series of test experiments that vary the Java heap settings. For example, run experiments with 128 MB, 192 MB, 256 MB, and 320 MB. During each experiment, monitor the total memory usage. If the heap is expanded too aggressively, paging can occur (use the vmstat command or the Windows NT or Windows 2000 Performance Monitor to check for paging). If paging occurs, reduce the size of the heap or add more memory to the system.

Important: Make sure that the heap never pages, as that would introduce a enormous performance loss.

When all test runs are finished, compare the following statistics: Number of garbage collection calls Average duration of a single garbage collection call Average time between calls Ratio between the average 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, a state of steady memory utilization is reached. Garbage collection also occurs less frequently and for shorter durations.

If the heap free time settles at 85% or more, consider decreasing the maximum heap size values, because the appserver and the application are under-utilizing the memory allocated for heap.

The best result for the average time between garbage collections is at least five to six times the average duration of a single garbage collection. If you do not achieve this number, the JVM is spending more than 15% of its time in garbage collection. FInding this point might require trial and error. A longer interval between garbage collection cycles can result in longer GC runs, while very short intervals can be inefficient.

 

Heap thrashing

Avoid heap thrashing at all costs. It is caused by a heap that is barely large enough to avoid expansion but not large enough to satisfy future allocation failures. Usually a garbage collection cycle frees up enough space for not only the current allocation failure but a substantial number of future allocation requests. But when heap is getting thrashed, each garbage collection cycle frees up barely enough heap space to satisfy just the current allocation failure. The result is that the next allocation request leads to another garbage collection cycle, and so on. This scenario can also occur due to lots of short-lived objects.

  Prev | Home | Next

 

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

 

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