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

Get WebSphere Studio Application Monitor V3.2 Advanced Usage Guide now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.