Vous êtes sur la page 1sur 17

Diagnostics with OracIe JRockit Mission ControI

This is the lab guide for Oracle JRockit Mission Control (JRMC) hands-on labs
first given at Oracle Open World 2008. t contains a number of exercises
designed to familiarize you with some of the key concepts in JRockit Mission
Control. Some of the exercises have been marked as bonus exercises - these
may be skipped in the interest of seeing as many different parts of Mission
Control as possible. You can always go back and attempt them when you have
completed the standard exercises.
Lab Setup
You will need to install Oracle JRockit Mission Control (JRMC 3.0.3) and setup
and Eclipse development environment with the JRockit Mission Control plugin:
see the instructions given below.
The lab materials are included in a zipped archive file. You can unzip this and
store it anywhere on your local machine. n this lab guide, we will refer to this
location as %LABDR%.
As part of these hands-on lab exercises, you will practice working with JRockit
Mission Control in two different modes:

1. RCP (Rich Client Platform) JRMC running as a standalone Java/Swing
application
2. Eclipse Plug-in JRMC running integrated into an Eclipse-based DE
The JRMC functionality is identical, whether it is running in RCP or Eclipse Plug-
in mode; however, where you want to combine JVM-level diagnostics with source
code view/editing using the Eclipse plug-in obviously provides better integration.
For the lab, you should install both the RCP and the Eclipse Plug-in versions of
JRMC, following the instructions below:

StandaIone JRockit Mission ControI InstaIIation
Download the Oracle JRockit Mission Control installer from:
http://www.oracle.com/technology/software/products/jrockit/index.html
Choose the appropriate install kit for your OS and select JRockit Mission Control
for Java version 6. Run the installer, which will install the both the JRockit JVM
and JRMC to your hard disk. The installer will also create a Windows Start menu
folder (Oracle JRockit Mission Control 3.0.3 for Java SE 6 (32-bit)) and this will
contain a shortcut which you can use to start JRMC.

You will need to edit the setenv.cmd script in the %LABDR% directory so that
JAVA_HOME is set to the JRE directory included with the JRMC installation (for
example, JAVA_HOME=c:\jrmc-3.0.3-1.6.0\jre); this is needed to ensure that
the two sample applications contained in Lab2a.bat and Lab3a.bat run using
JRockit, rather than a non-JRockit JVM that you might have set as default JRE
on your system. Other JVMs can be monitored using JRMC, but only JRockit will
give you access to the level of detail described in these labs.

EcIipse PIug-In InstaIIation/Configuration
The JRMC plug-in can be used with the Eclipse-based Oracle Workshop for
WebLogic DE, which is included with the WebLogic Server 10gR3 installer. t
can also be used with your (or a customer's) own custom Eclipse environment,
since it uses the standard plug-in mechanism for extending Eclipse functionality.

For this lab, we recommend that you use the Oracle Workshop for WebLogic DE
with the JRMC plug-in. You will find a Windows Start menu shortcut for Oracle
Workshop for WebLogic 10gR3 in the Oracle WebLogic folder. Start Workshop
(you will be asked to select a default project workspace use the default value)
and then follow these instructions to install the JRMC plug-in:
http://www.oracle.com/technology/software/products/jrockit/missioncontrol/updat
es/eclipse-3.3/jrmc/update-site-instructions/index.html

f you have not installed Oracle Workshop for WebLogic (or you installed Oracle
WebLogic Server 10gR3 as part of the Oracle FMW JDeveloper 11g release),
then you will need to install your own copy of the Eclipse DE. You can do this as
follows:

1. Download an Eclipse package from http://www.eclipse.org/downloads/.
For these lab exercises you will need at least the Eclipse Package for
Java Developers (Ganymede based on Eclipse 3.4.1), although if you
wish to use Eclipse to develop applications for WebLogic Server you
would want the Eclipse Package for Java EE Developers.

2. Once you have downloaded and installed the Eclipse DE, you should
configure it to run on the Oracle JRockit JVM to take full advantage of the
JRMC features:
http://www.oracle.com/technology/software/products/jrockit/missioncontrol/
updates/eclipse-3.3/jrmc/run-on-jrockit-instructions/index.html

3. Finally, you should install the JRMC Eclipse plug-in as documented here:
http://www.oracle.com/technology/software/products/jrockit/missioncontrol/
updates/eclipse-3.3/jrmc/update-site-instructions/index.html

To access the JRockit Mission Control Lab exercises from within Eclipse, you will
need to switch to use the %LABDR%/workspace workspace. Go to File->Switch
Workspace->Other and browse to %LABDR%/workspace. You should now see
project folders for the various lab exercises.
Exercise 1 - Starting JRockit Mission ControI
Start the standalone (RCP) version of JRockit Mission Control from the Windows
Start menu. A splash screen should show and after a little while you should be
looking at something like this:



This is the basic JRockit Mission Control environment. To the left you have the
JVM Browser. t will normally contain the automatically discovered JVMs, such as
locally running JVMs and JRockits running with the JRockit Discovery Protocol
(JDP) turned on. f the remote JVM you wish to connect to is not using the JDP
auto-discovery mechanism, you can use the JVM Browser to manually create a
connection to the JVM.

Exercise 2 - The JRockit Management ConsoIe
The JRockit Management Console is used to continuously monitor a running
JVM. f you have experience with JMX, you can think of it as a JConsole on
steroids. You can start the JRockit Mission Control Management Console on a
JVM by selecting the JVM in question in the JVM
Browser and selecting Start ConsoIe from the context
menu. You can also click the ConsoIe icon in the JVM
Browser, as shown in the picture to the right.

Exercise 2.a - The Overview
Make sure you have started the RCP version of JRockit
Mission Control as described above. Then start the
Lab2a program by executing the %LABDIR%\Iab2a.bat,
either from the command prompt or by double clicking it.

After a little while you should see the JVM running the
Lab2a class appearing in the JVM Browser under the
Discovered/LocaI node. Open a console by selecting
Open ConsoIe from the context menu of the JVM
running the Lab2a class.

You should now be at the Overview tab of the Management Console. You should
see something similar to the picture below:



n the overview tab you can remove charts, add new charts, add attributes to the
charts, plot other attributes in the velocimeters, log the information in the charts
to disk, freeze the charts to look at specific values, zoom and more. Since we're
short on time, we're simply going to add the current thread count to the
Processor chart.

Click the Add. button of the Processor chart. n the attribute selector dialog, go
to the FiIter text field and enter Th. There is only one matching attribute, Thread
Count. Select it, choose your favourite (non-blue) color and press ok. f
everything has gone according to plan, you should see the thread count weighing
in at around 20.

Bonus exercises:
1. 20-ish is not very precise though. Freeze the graph and hover with the
pointer over the Thread Count series for a little while. What is your exact
thread count?

2. You decide that you dislike the live set attribute and warm up a bit to the
Thread Count attribute. Exchange the Live Set attribute shown in the
velocimeter in the upper right corner of the Overview tab with the Thread
Count attribute.

Note: The velocimeter widget will improve greatly in the upcoming version
of JRMC, but the updated version of the velocimeter is unfortunately not in
the demo version provided today.

Exercise 2.b - The MBean Browser
n JMX lingo, the MBean browser is where you browse the MBeans available in
the platform MBean server. f you expose your own application for monitoring
through JMX and register them in the platform MBean server, your custom
MBeans will show up here. You can use the MBean browser to look at specific
values of attributes, change the update times for attributes, add attributes to
charts, execute operations and more.

What is the current garbage collection strategy?

Tip: Go to the bea.jrockit.management domain, select the GarbageCollector
MBean and look for the Strategy attribute in the Attribute tabIe.

Whilst browsing the java.lang Threading MBean, you encounter your old friend
the ThreadCount attribute. You decide that you enjoy it so much that you wish to
add it to the Memory chart on the Overview tab as well. Right click on the
attribute, select Add to Overview chart->Memory. Go back to the Overview tab
and enjoy the Dual ThreadCount Plotting Experience for a brief moment.


Bonus exercises:
1. Get a thread stack dump by executing the DiagnosticCommand
print_threads.

Tip: Browse to
bea.jrockit.management.GarbageCollector#DiagnosticCommand, select
the operations tab, select the operation execute with return type String
and that takes a single String argument. Press the Invoke button, then the
String button. Enter print_threads, press ok and then ok again.

Exercise 2.c - The Threads View
Short on time as we are, we skip to the Threads view. Rejoice at the discovery of
our old friend the Thread Count attribute in the upper chart! n the threads view
we can check if there are any deadlocked threads in our application. Turn on
deadIock detection by clicking the appropriate icon in the Live Threads toolbar,
as indicated below.



Next click on the DeadIocked column header twice to bring the deadlocked
threads to the top.

Tip: You can also turn off the automatic retrieval of new stack traces by clicking
the Refresh Stack Traces icon next to the deadlock detection icon on the
toolbar. This is usually a good idea while investigating something specific, as you
may otherwise be interrupted by constant table refreshes.

What are the names of the deadlocked threads? n which method and on what
line are they deadlocked?


Bonus exercises:
1. f you run this from within Eclipse, you can jump to that line in the
source and fix the problem. Right click on the offending stack frame
and jump to the method in question.

Tip: If you want to do this bonus exercise, it is better to wait until after
you've started running everything in Eclipse, i.e. at exercise 3.c or
later.

Exercise 2.d (Bonus) - Triggers
High CPU load can indicate trouble. Let's set up a trigger that alerts us when the
CPU load is above say 50 percent. Go to the Triggers tab. Click the Add.
button. Select the bea.jrockit.management.Runtime#CPULoad attribute.
Select the trigger value to be 0.5. Click Next. You can see a few different actions
that can be taken. Let's stick with the default (AppIication aIert). Click Next. You
can add constraints for when the action is allowed to be taken. We do not want
any constraints for this trigger rule. Click Next once more. A name will be
suggested for the trigger rule. Hit Finish. Trigger rules are by default inactive.
Let's enable the trigger by clicking the checkbox next to its name. The rule is now
active. Move over to the Overview and wait for one of the computationally intense
cycles to happen. The Alert dialog should appear and show you details about the
particular event.

Disable or remove the rule when done to avoid getting more notifications.

Exercise 3 - The JRockit Runtime AnaIyzer
The JRockit Runtime Analyzer (JRA) is the main JRockit Mission Control Java
and JVM profiler. The recording part is built into JRockit and gathers data about
both JRockit and the application running in JRockit. To prepare for these labs
first close down the Management Console, then stop the Lab2a program by
going to the console (the command line window) where it was started and hit ctrl-
c. t should be the one looking similar to the picture below:



Also, to save Eclipse from Death by Out of Memory, remember to close the JRA
recordings after each lab.
Exercise 3.a - Starting a JRA Recording
There are various different ways to start a JRA recording. We will do it from
within Mission Control for this exercise. Start the Lab3a program by running
%LABDIR%\Iab3a.bat. After it appears, right click on the JVM running the Lab3a
program, and select Start JRA Recording. n the JRA Recording Wizard, select
to make a normal recording for two minutes. Make sure you save the file where
you can later find it. Hit ok to start the recording.



After the two minutes are up, you should be looking at an Overview tab with a
whole lot of textual information (in the current version, 3.0.3 the next version,
currently in beta, has a nice graphical overview of the recording).

Exercise 3.b - Hot Methods
One class of profiling problems deals with finding out where the application is
spending the most time executing. Such a "hot spot is usually a very good place
to start optimizing your application, as any effort bringing down the computational
overhead in such a method will affect the overall execution of the application a
lot. Skip to the Methods tab. One of these methods has a lot more samples than
the others. This represents that the JVM has spent more time executing that
method relative to the other methods. Which method is the hottest one? From
where are the calls to that method originating?

Which method do you think would be the best one to start optimizing to improve
the performance of this application?

Tip: Often the hotspot is in a method beyond your control. Look for a
predecessor that you can affect.

Bonus Exercises:
1. Fire up Eclipse and open your recording from within Eclipse. Can you, by
changing one line of code, make the program much more effective (more
than a factor 10)?

A note on starting Eclipse
The next couple of exercises will be done from within Eclipse. Refer back to the
Lab Setup section at the beginning of this lab guide for instructions on installing
and running Eclipse (as Workshop for WebLogic or other Eclipse package). You
will need to configure Eclipse to use the workspace %LABDR%/workspace, as
described in that section.

Exercise 3.c - Latencies
Another class of profiling problems deals with latencies. Usually the symptom is
that you do not get the throughput you expect in your application, but the CPU is
not saturated. This is usually due to your threads of execution stalling, for
example due to bad synchronization behaviour in your application. The Latency
Detection tool is a good place to start investigating this category of problems.

Like any good cooking show, we've provided you with a pre-recorded recording,
to save you from having to wait another minute or so for the recording to finish.
Open up the recording Iab3_Iatency.jra in the project Exercise 3c by double
clicking it.

Click on the Latency Graph tab and ensure that the Event Types view is visible
in the top left corner. What type of event seems to be the dominating one?

Select one of the dominating events. From where is that event originating?

Tip:Look in the properties view.


n the properties view, click on the Event Properties icon in the toolbar of the
Properties view. t is the rightmost icon. Of what class is the lock we're blocking
on? What threads are involved?

Move over to the Latency Traces tab. Click the Latency tabIe coIumn header
to sort the traces on the total latency contributed. Expand the trace that
contributes most to the latency. Note: In this case it is a very shallow trace. In a
more complex scenario it would of course have been deeper. t seems most of
these blocking events come from the same source.

Let's take a step back and consider the information we've gathered. Most of our
worker threads seem to be waiting on each other attempting to get the Logger
lock. All calls to that logger seem to be coming from the WorkerThread.run().

Can you think of a few ways to fix this?

Tip: Right click on the Logger.log(String) method and select Open Method. We
get two matches; select the Lab3c one. The method is synchronized.

There are a few ways to fix this available to us. We can cut the call to the logger
altogether. If the logging doesn't use a shared resource, we can just remove the
synchronization from the log method. We can also, provided no underlying
synchronization takes place in whatever we log to, provide each logger thread
with its own logger instead of sharing one.

n the Iab3_Iess_Iatency.jra recording we simply removed the synchronized
keyword from the Logger.log(String) method. Can you see any difference to the
other recording? Are the threads getting to run more or less than before? Are we
getting better throughput now?

Tip: You can compare recordings side by side by dragging and docking the
editors that contain them the standard Eclipse way.

Tip: The cpu load is by default shown as a dark line in the Time Range SeIector
above the Latency tabs.

Exercise 3.d (Bonus) - Memory Allocation Profiling
This bonus exercise will show a powerful way of determining the pressure on the
memory system. This is a real world example; unfortunately no source will be
provided. Open the object_aIIocation.jra recording in the Lab3d project. Click
the Latency Log tab. n the Event Types view (upper left) ensure that the Object
AIIocation event type is checked.

Go to the Latency Log tab and select the Event Property Histogram. n the
upper right combo box, select Object AIIocation - CIass Name.

What kind of Object allocation seems to be causing the most pressure on the
memory system?

Let's say we want to investigate the allocations of strings further. Right click on
java.lang.String in the histogram and select Operative Set->Set seIection. Don't
mind that the combo box selection changed. That is a bug which has already
been fixed in the beta version.

Tip: The operative set can be seen as a bag of events you can add and remove
from. The latency views can all be filtered to only show what is in the operative
set. It is a powerful way to bring a selection of events between the views to
visualize them in different ways.

Select the Latency Traces tab and check the Show onIy Operative Set check
box. Now you're looking at the events that caused the String allocation events. f
we wanted to minimize the pressure on the memory system, minimizing String
allocation in the method with the most samples would be a very good place to
start.

Tip: Minimizing the pressure on the memory system leads to less garbage
collections and thus less latency.
Exercise 3.e (Bonus) - Garbage Collection Behaviour
While JRockit tuning is out of the scope for this set of exercises, this exercise will
show how to get very detailed information about the Garbage Collections that
happened during the recording.

Go to the Lab3.e project and open the lab3e.jra recording. Go to the GCs tab. n
this tab you can see almost all there is to know about each and every garbage
collection that happened in JRockit during the recording.

f you click on the little table properties icon in the toolbar over the Garbage
CoIIection tabIe, you can see that only three of over fifty data points available
for each garbage collection are currently shown in the table. Click on the Sum of
Pauses tabIe coIumn header to sort the garbage collections on which caused
the most total pauses in the JVM. How long was the longest one? Select the
longest garbage collection, and then click on the GC method caII tree tab. What
seemed to cause that pause?

Click on the Pause Time tab, and then Sort on Duration. n what part of the
garbage collection did we spend the most time?

Use the technique in the previous exercise to confirm what method is causing
these allocations.

Bonus Exercise:
1. Can you, with a very simple rewrite of the inner MyAlloc class only, cause
almost all object allocations to cease and almost no garbage collections to
happen, while keeping the general idea of the program intact?

Tip: The cause is involuntary auto-boxing.

Exercise 3.f (Bonus) - More Garbage Collection Behaviour
Open the JRA recording lab3f.jra in the Lab3f project.

How much time was spent collecting garbage? What do you think is happening?
Note: This one is a little bit tricky.

Tip: You can see the total accumulated GC time in the GC GeneraI tab. For any
given garbage collection, what part of the garbage collection takes the longest
time? In the GCs tab use the combo box in the upper right corner to switch to
looking at the References and FinaIizers.

Bonus Exercise:
1. Fix the problem in the code.

Tip: You can fix this by simply removing one method that isn't doing much
for us anyway.

2. Do another one minute recording after you have fixed the application. How
much time is spent in garbage collections now?

Exercise 4 - The JRockit Memory Leak Detector
The JRockit Memory Leak Detector can be used both for finding memory leaks
as well as powerful online analysis of the heap.
Exercise 4.a - Finding a Memory Leak
Start the Lab4a program. Switch to the Mission Control perspective. Right click
on it once it appears under the Local JVMs in the JVM Browser and select Start
MemIeak. Let it run for a little while. You should be getting candidates for the
memory leak.

We now want to know who's holding on to references of our most wildly leaking
type. Right click on it and select Show Referring Types from the context menu.
You should be looking at the graph. The redder a type node is, the more
suspicious the type is in regards to the memory leak. Follow the most suspect
types by clicking the green plus icons in the type nodes. You should be ending
up in some sort of hash table. t seems someone is abusing a hash table in some
way. But which one?

List all the instances of the inner class DemoObject. Since there are a lot of
them, the JVM will time out and return a subset of them and display a warning.
Don't worry about that. You can set the time out to whatever you want to in the
preferences. After the 30 second default time out, pick an instance, right click on
it and select Show referring instances from the context menu. Follow the
references until you find the exact field name of the hash table that keeps the
reference. You should find that the inner class DemoThread in class Lab4a is
holding onto them through a field named "table. Proper heuristics for that hash
table would take care of our leak.

We can also find out where objects of a certain type are being allocated. Go back
to the Trend tab. Right click on the Lab4$DemoObject cIass and select Show
aIIocation traces from the context menu. Let it run for a while. You'll see that
there are slightly more being allocated in the put as compared to the remove
method. Right click on the method and select View Method source.

Bonus Exercises:
1. Can you see what is causing the memory leak?
2. Fix the code and verify that the leak is gone.
Exercise 4.b (Bonus) - Heap analysis
The Memory Leak detector is also a very powerful on-line heap analysis tool.
Let's find the hashtables in the system that in turn contain hashtables and keep
alive the most memory. Go back to the Trend table and select the
Lab4$DemoObject cIass and follow the references all the way back to
java.util.Hashtable and then expand Hashtable one more step. You should be
seeing a circular dependency in the graph.



We only want hashtables pointing to hashtables. Select the Hashtable$Entry
node, right click on it and select List instances from the context menu. Since the
Hashtable$Entry node is participating in many relationships we get a dialog
prompting us to specify what instances to list. Select the ones pointing to
java.util.Hashtable. You should see that there are five hashtable entries pointing
to hashtable. Two of them are keeping alive considerably more memory than the
other ones. Take the largest one, right click on it and select Show referring
instances from the context menu. n what class is the hashtable located? What
is the field called?
Exercise 4.c (Bonus) - On Line Leak Hunting
This exercise shows how to hunt for memory leaks while interacting with the
application. Start the Lab4c application. For this exercise we need to set the
cutoff value for the JRockit Memory Leak detector to 0, since we want to track
changes in classes that only have a few instances. Go to the top menu in Eclipse
and select Window->Preferences. Type Trend in the fiIter text fieId in the
upper left corner of the Preferences dialog. Select the Trend node and enter 0 in
the text field named Lowest heap usage to report. And enter 3 in the text field
named Trend refresh intervaI.



Hook up a JRockit Memory Leak detector to the Lab4c application by right
clicking on the Lab4c running JVM in the JVM Browser. n the Type fiIter at the
bottom of the Trend tab, type Lab4. You should now see the Lab4c class and its
inner classes.

Try keeping the trend graph open and visible in the background while playing
around with the application. What happens if you add and remove multiple
addresses? Can you see what is wrong? Can you find out exactly who is holding
on to the offending references?

Tip: To only have invalid references left, it is easiest to clear all the addresses
first.

Bonus exercises:
1. Can you fix the application?
2. How do you go about verifying that it is fixed with the JRockit Memory
Leak Detector?

Exercise 5 - JRCMD (JRockit Command)
This exercise will explain the basic usage of the JRockit command line tool
jrcmd. You can find it in the JRockit distribution under JROCKIT_HOME/bin, for
instance under %LABDIR%\jrmc_3.0.3\bin. t will already be on the path if you
open the command line interface in the same manner as the previous labs.

Start any Java application. f you already have Eclipse or the RCP version of
Mission Control running, you are already running one and can skip this step.

Next open a command prompt by double clicking %LABDIR%\cmd.exe. At the
prompt type jrcmd and hit enter. This will list the running java processes and
their Process Ds (PD). Since JRCMD uses Java, and it is running it will list itself
as well.

The jrcmd uses the PD to identify what JVM to talk to. Type jrcmd <PID> heIp,
for example jrcmd 4711 heIp. That will list all available diagnostic commands. f
<PD> is set to 0, the command will be sent to all running JRockits.

Attempt to list the versions of all running JRockits.

Bonus exercises:
1. Start the Lab4a program. Use the print_object_summary command.
Wait for a little while, and then run it again. Can you find any specific use
for it?

2. You decide that you want your friend to access a JRockit running a server
that has been up for a few days from his computer to help you solve a
problem. Oh dear, you didn't start the external agent when you started the
server, did you? Can you find a solution that doesn't involve taking the
server down?

Tip: If you want to try the solution without specifying keystores and
certificates, make sure you specify ssl=false authenticate=false. Also,
specifying a free port is considered good form. Using ssI=faIse
authenticate=faIse port=4711 should be fine.

3. Could you start JRA recordings using jrcmd? How?

4. Start the Lab5 application. Switch to the debug perspective, select the
Lab5 application then maximize the ConsoIe view in the lower right
corner by double clicking it. Keep the console visible, but go back to your
Windows cmd console and use jrcmd without arguments to find the PD of
Lab5. Run jrcmd <PID> verbosity set=exceptions=info. Watch the
Eclipse console output for Lab5. What is happening? Execute jrcmd
<PID> verbosity set=exceptions=debug. What can this be used for?
Finally execute jrcmd <PID> verbosity set=exceptions=quiet.

Tip: You can use this to set the verbosity level for other modules in
JRockit. Using it for dynamically enabling exception profiling, like in the
example above, is a quite useful example.

Note: Have you noticed that there is a very similar feature set available from the
Diagnostic Commands discussed in Exercise 2.b and jcrmd? As a matter of fact
everything you can do from jrcmd you can do using the DiagnosticCommand
MBean and vice versa.

Vous aimerez peut-être aussi