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

Availability:

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

10/22/2013

pdf

text

original

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]
com/caucho/java/CompilingClassLoader

<2>

[270,164,496] 0x10053d18 [168]
com/caucho/util/DirectoryClassLoader
- 14 children of 0x10053d18 too deep.

<2>

{270,167,680} 0x10053c70 [168]
com/caucho/java/CompilingClassLoader

<2>

<270,163,200 parent:0x10053d18> 0x10053dc0 [168]
com/caucho/java/CompilingClassLoader

<2>

<270,163,200 parent:0x10053d18> 0x10053dc0 [168]
com/caucho/java/CompilingClassLoader

94

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:

Addr

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
com/arsdigita/london/theme/util/ThemeDevelopmentFileManager
N 0x1cbc24b0 32 0x100a2ef8 0x1e18a5a8 2,460,464
com/arsdigita/templating/XSLTemplate
N 0x23180b28 80 0x100a2ef8 0x22bc0ee8 2,164,688
com/arsdigita/london/search/RemoteSearcher
N 0x1bf215e0 56 0x100a2ef8 0x1bf2a850 1,844,152
com/arsdigita/persistence/Session
N 0x1bf2ab98 40 0x100a2ef8 0x1bf215e0 1,770,096
com/arsdigita/persistence/TransactionContext
N 0x1affda20 16 0x100a2ef8 0x1aa4d388 1,681,056
com/arsdigita/persistence/DataQueryImpl$UnaliasMapper
N 0x1affc508 96 0x100a2ef8 0x1affda20 1,681,040
com/arsdigita/persistence/DataAssociationCursorImpl
N 0x1a985ff0 56 0x100a2ef8 0x1a98e8e8 1,138,696
com/arsdigita/bebop/PageState

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
com/arsdigita/templating/Templating
<1> [224,092,408] 0x28500840 [56] java/util/HashMap
<2>

[224,092,352] 0x1cdf9160 [1,552] array of
java/util/HashMap$Entry

<3>

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

<4>

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

<4>

[1,069,960] 0x2c824ca8 [32]
com/arsdigita/templating/XSLTemplate
- 4 children of 0x2c824ca8 too deep.
- 1 child of 0x2dbfa500 filtered.

<3>

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

<4>

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

<4>

[1,069,912] 0x237796b0 [32]
com/arsdigita/templating/XSLTemplate
- 4 children of 0x237796b0 too deep.
- 1 child of 0x263c8ff8 filtered.

<3>

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

<4>

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

<4>

[1,069,912] 0x1864f950 [32]
com/arsdigita/templating/XSLTemplate

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

95

- 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

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