Using the garbage collection perspective

View data such as heap usage, pause times, summary table, object allocations, and tuning recommendation sections in the Health Center garbage collection perspective. Some data is not available for non- Java™ applications.

The Health Center garbage collection perspective has the following views:

Views for basic garbage collection information
These views are available for all application types:
Views for detailed garbage collection information
These views are available only for Java applications, and only if you enable detailed garbage collection information according to the instructions in Controlling the collection of garbage collection information (Java applications only):
  • Object allocations: A table that shows the allocation of objects within a specified size range.
  • Samples by request site: A profile of sampled object allocations, grouped by the call site of the allocation request.
  • Samples by object: A profile of sampled object allocations, grouped by the type of object allocated.
  • Call hierarchy: This view shows data when you select a row in the Object allocations, Samples by request site, or Samples by object views. For example, if you select a row in the Samples by object view, this view shows the hierarchy of calls to allocations of that object.
  • Timeline: A visual indication of when object allocations were requested. This view shows data when you select a row in the Object allocations or Samples by request site views.

Heap usage

Use the graph of heap usage to identify trends in application memory usage. If the memory footprint is larger than expected, a heap analysis tool can identify areas of excessive memory usage. If the used heap is increasing over time, the application might be leaking memory. A memory leak happens when applications hold references to objects that are no longer required. Because these objects are still referenced, they cannot be garbage collected and contribute to memory requirements. As the memory consumption grows, more processor resources are required for garbage collection, leaving fewer for application work. Eventually the memory requirements can fill the heap, leading to an OutOfMemoryError exception, and an application failure.

When monitoring a WebSphere® Real Time for Linux JVM, you see a used heap graph that has a typical pattern of regular spaced collections.

Pause times

Use the graph of pause times to assess the performance affect of garbage collection. When garbage collection is running, all application threads are paused. For some applications, such as batch-processing, long pauses are not a problem. For other applications, such as GUI applications or applications that interact with other systems, long garbage collection pauses might not be acceptable.

Longer garbage collection pauses are often associated with better application throughput and are not a performance problem. Spending extra time in garbage collection can often lead to improved memory allocation and memory access times. The aim of garbage collection tuning is to have reduced pause times only if low response times are required.

Object allocations

Use the object allocations view to identify which code is allocating large objects. You can use low and high-threshold values to specify the object range that triggers collection of the call stack information. For more information, see Controlling the collection of garbage collection information (Java applications only).

The view displays a table showing the following information:
Table 1. Object allocations
Column Heading Description
Count The number of allocation requests at this request site
% The percentage of recorded allocations at this request site
Allocations A graphical representation of the % column
Average size (KB) The average object size for the recorded allocations
Request site The code location of the allocation request
Select a row in the table to display the call paths to the allocation request site in the Call hierarchy view. The Timeline view gives a visual indication of when the allocations were requested.

Samples by request site or object

Use these views to identify code that is allocating large numbers of objects.

An allocation sampling event occurs when the JVM has allocated a specified amount of memory outside the thread local heap. This amount of memory is defined by the -Xgc:allocationSamplingGranularity=bytes option. The default value is 16 MB. The number of sampling events depends on the amount of memory that the monitored application requests. To increase the number of samples, reduce the value of the -Xgc:allocationSamplingGranularity option. For the maximum number of samples, set -Xgc:allocationSamplingGranularity=1.
Note: Setting the value of the -Xgc:allocationSamplingGranularity option to less than the default value might affect the performance of the monitored JVM.
For more information about the thread local heap, see the "Thread local heap" topic in the documentation for your version of IBM SDK, Java Technology Edition. For example Thread local heap.
Use the Samples by request site view to find code that is issuing allocation requests most frequently. Data is displayed only when you enable the collection of call stacks for sampled object allocation events. For more information, see Controlling the collection of garbage collection information (Java applications only). This view displays a table with the following columns:
Table 2. Samples by request site
Column Heading Description
Count The number of sampled allocation requests for this object type
% The percentage of sampled allocations for this object type
% A graphical representation of the % column
Request site The code location of the allocation request
Allocated Object The class name of the object being allocated at this site
Select a row in the table to display the call paths to the allocation request site in the Call hierarchy view, and a visual representation of when the allocation requests were made in the Timeline view.
Use the Samples by object view to find the objects that are being allocated most frequently. This view displays a table with the following columns:
Table 3. Samples by object
Column Heading Description
Count The number of sampled allocation requests for this object type
% The percentage of sampled allocations for this object type
% A graphical representation of the % column
Total size (KB) The total memory allocated by the sampled allocations
Allocated Object The class name of the object being allocated
Select a row in the table to display the call paths to the allocation request site in the Call hierarchy view. The call hierarchy information is only available if you enable the collection of call stacks for sampled object allocation events. For more information, see Controlling the collection of garbage collection information (Java applications only).

Summary table

The summary table shows garbage collection metrics, including mean pause time, mean interval between garbage collections, and the amount of time spent in garbage collection. The time an application spends in garbage collection must not be taken as a performance metric itself. Some garbage collection policies, such as the generational concurrent (gencon) policy in the IBM SDK, Java Technology Edition, can take more time in garbage collection but still provide improved application performance.

Tuning recommendations

The Health Center provides general tuning recommendations and advice for Java applications. In exceptional cases, further fine-tuning might be required. The Health Center does not know what your quality of service requirements are, therefore the recommendations are not always useful. For example, a suggested change might improve application efficiency but increase pause times, which might not be best for your application. The tuning recommendations also indicate if the application seems to be leaking memory. However, the Health Center cannot distinguish between naturally increasing memory requirements and memory that is being held when it is no longer required.

Viewing data for a particular time period

You can select the time interval for displaying data, and making recommendations, by using cropping. For further information about cropping, see Cropping data.