Checklist/Tuning Guide for Optimizing the JRockit JVM
by Steven Pozarycki
12/13/2007
Abstract
The goal of this document is to provide information for tuning the BEA
JRockit JVM using a checklist approach. A lot of territory is covered, from esoteric command-line options to iterative performance testing. I gathered most of these data working with customers. If you have additional tips, please send them to me and I'll try and incorporate them in a later version of this document.
Specific product version information is outlined where applicable;
however, general guidelines outlined here apply to most versions of JRockit.
New settings and optimizations are added with every JRockit release, so
check the release notes and
the JRockit Product Center.
The first thing to do is to confirm the JRockit version being used by your runtime application server. You can do this by looking at the log file of the application server in question. This can also be done by setting your environment with the appropriate script and then doing a java -version to confirm the JRockit version that is running.
Next, gather the current JVM flags that are being used in development and/or
production. For example, they could look like the following at startup:
-server -Xms1024m -Xmx1536m -Xverboselog:gc.log -Xverbose:memory
-Xgcprio:throughput
This will tell you how your current JRockit instance is configured.
Determine the Goal of the Application
Determine what the goal of the application is. Is it "short response
times" or is it "high application performance"? Depending on the goal,
different garbage collection algorithms need to be set.
For example, if the goal is high application performance, confirm that
the Dynamic Garbage Collector "-Xgcprio:throughput"
is set. If short response times are your goal, then -Xgcprio:pausetime -Xpausetarget=XXX' with the pausetarget value set to a value would be optimal. Review the JRockit
tuning
section documentation for further details.
Gather Troubleshooting Data
If you have performance issues with the JVM, then the best course of action is to first gather some data for analysis. This can be done by someone on your team who is experienced in such matters, or this information can be sent to BEA Support for further analysis.
The first step is to gather a JRockit Recording (JRA) of about 10
minutes of the runtime while the problem is occurring. You can do this by
using the jrcmd.sh utility or JRockit Mission Control
(JRMC). See the sections below on "JRCMD/JRA
during performance tests" and "JRockit Mission Control." And be sure to review the JRockit Mission
Control documentation for further details. One valuable item to look at is
the Latency Analysis section, which gives you insight into any latency
issues (available with a license enabling this in JRockit).
The second step is to gather some verbose logging during the time
of the problem. You can accomplish this by supplying the following
arguments to the JVM command line when starting the server instance:
-Xverboselog:perTestGC.log
-Xverbose:opt,memory,gcpause,memdbg,compaction,gc,license
-Xverbosetimestamp -Xgcreport
This will gather valuable data for analysis into the perTestGC.log
file configured above. This data can be analyzed by someone on your team
and/or BEA Support.
One last point: Usually, applications do not make requests to do a garbage collection (that is, calling System.gc() within the application code). However, an option can be supplied to disable this with the -XXnoSystemGC flag on the Java command line when starting the server instances, in case you suspect that this could be an issue.
Let's now look at iterative performance testing approaches for nailing
down the problems.
| 
Bookmark
