P. 1
RHEL Tuning Guide

RHEL Tuning Guide

|Views: 106|Likes:
Published by chasitb

More info:

Published by: chasitb on May 28, 2012
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Having set the IBM_HEAPDUMP=true environment variable and restarted the servers, wait for the
performance slowdown to reoccur (which indicates that the garbage collector is starting to thrash).
When it does, send a SIGQUIT to the root process, which generates a heapdump file about 850 MB
in size. Then load this into the HeapRoots analysis program:

java -jar /tmp/HR205.jar heapdump3632.1083842645.txt

After parsing the file, heaproots shows a few basic statistics about the dump:

# Objects

: 7,727,411

# Refs

: 12,807,015

# Unresolved refs : 31
Heap usage

: 315,413,344

The first thing to do is to invoke the process command. This resolves all references between the
objects, detects roots, and calculates total size metrics per class and sub-tree.

Pure roots

: 174,088

... which reach

: 7,706,600

Artificial roots

: 1,531
Softlinks followed : 16,014

Now, you are ready to answer some interesting queries. Look to see what the biggest tree roots are.
This was done by running the dt command (Dump from roots, sort by total size). The command
prompts for some values such as the maximum depth to print out and the minimum size threshold,
then it produces something similar to this:

<0> [270,167,808] 0x100a2ef8 [72] java/lang/Thread
<1> [270,167,680] 0x10053c70 [168]


[270,164,496] 0x10053d18 [168]
- 14 children of 0x10053d18 too deep.


{270,167,680} 0x10053c70 [168]


<270,163,200 parent:0x10053d18> 0x10053dc0 [168]


<270,163,200 parent:0x10053d18> 0x10053dc0 [168]


Chapter 8. Analyzing Java Application Performance Problems Using the IBM JVM

- 13 children of 0x10053c70 filtered.
- 4 children of 0x100a2ef8 filtered.
<0> [5,234,712] 0x16a85b90 [447,296] array of java/lang/Object
- 111820 children of 0x16a85b90 filtered.

Unsurprisingly, the root with highest memory consumption is the top level thread of the JVM. This
implies the memory leak is in the application code, so look for the biggest object in a package whose
name began with the name of the application provider (com/arsdigita/in this example). Todo this,
use the “Objects dump, sort by total size” command (ot com/arsdigita/). Again this prompts for
some more optional filters, but accepting the defaults produces a list of large objects:


Size Root-owner Parent

Total-size Name
N 0x284ffb48 256 0x100a2ef8 0x284ffc88 224,107,816
class com/arsdigita/templating/Templating
N 0x220d3458 96 0x100a2ef8 0x22bc0ee8 4,585,520
N 0x1cbc24b0 32 0x100a2ef8 0x1e18a5a8 2,460,464
N 0x23180b28 80 0x100a2ef8 0x22bc0ee8 2,164,688
N 0x1bf215e0 56 0x100a2ef8 0x1bf2a850 1,844,152
N 0x1bf2ab98 40 0x100a2ef8 0x1bf215e0 1,770,096
N 0x1affda20 16 0x100a2ef8 0x1aa4d388 1,681,056
N 0x1affc508 96 0x100a2ef8 0x1affda20 1,681,040
N 0x1a985ff0 56 0x100a2ef8 0x1a98e8e8 1,138,696

As you can see, the class object for com.arsdigita.templating.Templating is taking up 224
MB of the heap. A quick look at the code shows it has a static HashMap storing XSLTemplate objects
with no size bounding. To confirm this is the problem, got back to the “Dump from roots, sort by total
size” command, this time starting the display from the object at address 0x284ffb48:

<0> [224,107,816] 0x284ffb48 [256] class
<1> [224,092,408] 0x28500840 [56] java/util/HashMap

[224,092,352] 0x1cdf9160 [1,552] array of


[4,288,800] 0x2dbfa500 [32] java/util/HashMap$Entry


[3,216,568] 0x1bf5cc00 [32] java/util/HashMap$Entry
- 3 children of 0x1bf5cc00 too deep.


[1,069,960] 0x2c824ca8 [32]
- 4 children of 0x2c824ca8 too deep.
- 1 child of 0x2dbfa500 filtered.


[3,216,584] 0x263c8ff8 [32] java/util/HashMap$Entry


[2,144,416] 0x3d00ade8 [32] java/util/HashMap$Entry
- 3 children of 0x3d00ade8 too deep.


[1,069,912] 0x237796b0 [32]
- 4 children of 0x237796b0 too deep.
- 1 child of 0x263c8ff8 filtered.


[3,216,568] 0x19319d58 [32] java/util/HashMap$Entry


[2,144,400] 0x33ddd918 [32] java/util/HashMap$Entry
- 3 children of 0x33ddd918 too deep.


[1,069,912] 0x1864f950 [32]

Chapter 8. Analyzing Java Application Performance Problems Using the IBM JVM


- 4 children of 0x1864f950 too deep.


<1> {224,107,816} 0x284ffb48 [256]
class com/arsdigita/templating/Templating
- 15 children of 0x284ffb48 filtered.
There were 362 objects expanded.

From this it is clear that the problem is a huge HashMap in the Templating class containing around
one hundred XSLTemplate objects, each around 1 MB in size.

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->