WebSphere Studio Application Monitor V3.2 Advanced Usage Guide

108 WebSphere Studio Application Monitor V3.2 Advanced Usage Guide

classes that have grown the most. We will use these classes to actually

determine the memory leak.

Figure 5-8 Memory Leak candidate comparison report

5.2.4 Determining the memory leak offender

With potential leaking classes identified from step 2 of the Memory Leak report,

determine which classes are causing the leak in step 3, the Memory Leak

Diagnosis report. This report finds the most-leaked objects and shows the class,

method, and line number of the allocating class of leaked objects to help the

programmer determine the trouble spots of code.

Tip: By default, classes that are filtered out by the Monitoring configuration are

excluded from the analysis. Though you may not want to monitor the basic

classes such as Strings and Lists, these objects can often be a source of

leaks and should be examined. To do this, clear the Exclude section of the

Classname Filter Option and click Apply to see everything in the heap. (This is

done dynamically without re-executing the report.) Then selectively exclude

classes and packages that are not a concern. Finally, sort from most to least

the column that shows change in the number of instances. The result will be a

richer look at the objects that are growing in memory.

Chapter 5. Analyzing WebSphere application problems 109

Configuring the Memory Leak Diagnosis report

To set up the Diagnosis report, reconfigure the data collector to monitor the growth

classes found in 5.2.3, “Narrowing the cause of a memory leak” on page 106.

The Memory Leak Diagnosis report is set up in an XML file on the data collector in

the <am home>/etc directory. The bcm.properties file has a key/value pair called

userbcm.xmlfilename that identifies which XML configuration file is used. Adjusting

the bcm.properties files allows for multiple XML files to be swapped in and out.

The XML file is composed of multiple sections of selectClass tags that identify

how to treat classes matching the mask pattern. The XML snippet in

Example 5-1 shows the modification to monitor memory leaks.

Example 5-1 XML for monitoring memory leak

<selectClass>

<mask>*</mask>

<methods>

<methodName>*</methodName>

</methods>

<ignoreTrivial>true</ignoreTrivial>

<lockAnalysis>true</lockAnalysis>

<objectAllocations>

<allocateClass>*</allocateClass>

</objectAllocations>

<objectAllocationTimes>true</objectAllocationTimes>

</selectClass>

Only classes found inside the allocateClass tag are monitored as potential leaks.

An asterisk in the tag will monitor all classes for leaks, but a better strategy is to

use the top classes from step 2 (Figure 5-8 on page 108) for further analysis. If

step 2 does not offer any good candidates, using the asterisk to turn it on allows

for all objects to be monitored, but this has an adverse impact on performance.

Setting the objectAllocationTimes tag to true enables the Growth % and Growth

Rate columns, which can help show the rate of growth in the objects.

Note: WebSphere Studio Application Monitor generates a server-specific

bcm.properties file called <host name>.<app server name>.bcm.properties.

When changes are made to the original bcm.properties, the generated version

must be deleted so that WebSphere Studio Application Monitor knows to

regenerate the bcm.properties.

Important:

The Diagnosis report is functional only in L3 mode. It can slow down a

production system severely and should be used only in controlled test situations.

110 WebSphere Studio Application Monitor V3.2 Advanced Usage Guide

Using the Memory Leak Diagnosis report

The memory leak diagnosis report is step 3 of the Memory Leak report. You

select the group and server to get to the Report’s table. The report result is a very

wide table. Figure 5-9 shows the overall result.

Figure 5-9 Memory leak diagnosis report