 |
» |
|
|
|
To take full advantage of HPjmeter functionality, you can gather profiling
data using -Xeprof for
performance tuning and -agentlib:hprof for
memory tuning when you run your application.
| | | |  | NOTE: If you are running the HP JDK/JRE 5.0.04 or later, you can send a signal
to the running JVM to start and stop a profiling data collection period with
zero preparation and no interruption of your application. See Profiling with Zero Preparation . | | | | |
Profiling with -Xeprof | |
To profile an application, use the following command: java -Xeprof:options ApplicationClassName |
To profile an applet, use the following command: appletviewer -J-Xeprof:options URL |
where options is
a list of key[=value]
arguments separated by commas. You can also stop the JVM (kill pid)
or control the profiling time using the time_on or time_slice options.
See the descriptions in the list of options. The following options are especially useful in most cases: For CPU time, clock time, and lock contention metrics with
minimal intrusion, use-Xeprof For exact call count information and non-array object creation
profiling, use-Xeprof:inlining=disable
To see the complete list of available options, use java -Xeprof:help -Xeprof always collects call graph data with inclusive
method times (clock and CPU), method call count, and lock contention metrics.
This option uses tracing with reduction and collects the data separately for
each thread. To see the availability of HPjmeter metrics from -Xeprof data
collection, see –Xeprof and –agentlib:hprof Profiling Options and Their
Corresponding Metrics. Table 5-1 Supported -Xeprof options | time_on=integer | Specifies the time in seconds between the application start and the
time when the profile data collection will start. If no time_on option
is present, the data collection begins at the VM initialization. | | time_on=sigusr1|sigusr2 | Specifies which signal will cause profiling to begin (profile
data collection). Be aware that the application or the VM may already be using
the sigusr signals for their own purposes. Specifying a signal and a timeout at the same time is possible
by repeating the time_on option. Only one of the two signals can be declared to use as the
signal to start profiling. During the application's run, the specified signal can be
delivered to the Java process multiple times.
| | time_slice=integer | Specifies the time in seconds between the profiling start and
the time when profiling will be terminated. When the profiling is terminated, the profile data is written
to a file. The application will continue running. If time_slice is not specified, or if the
application terminates before the specified time elapses, but the profiling
has started, the profile data will be written out after the termination of
the application.
| | time_slice=sigusr1|sigusr2 | Specifies which signal will cause profiling termination and the
profile data output. The signals for profiling start and profiling termination
can be the same. Specifying a signal and a timeout at the same time is possible
by repeating the time_slice option — termination of
profiling occurs when the first qualifying event takes place. The application
will continue running. Only one of the two signals can be declared to use as the
signal to terminate profiling. During the application's run, the signal to terminate profiling
can be delivered to the Java process multiple times. However, profiling will
only be terminated and a result file generated if profiling is active when
the termination signal is delivered.
| | file=filename | The profile data will be written to the named file. If time_on=sig... has not been specified,
the default is filename.eprof If a signal has been specified to start profiling, several data files
can be created, with names filename_t.eprof,
wheret is the time in seconds between the application
start and the profiling start.
| | inlining=disable|enable | The compiler in the HotSpot VM optimizes Java applications by inlining
frequently called methods. Execution of an inlined method is not reported
as a “call” because the actual call has been eliminated. Instead,
the time spent in an inlined method is attributed to its “caller” The
consequences of inlining for profiling can be characterized as follows:
The obtained profile data does not reflect faithfully all
the calls within the Java code as written by the programmer, but rather as
it is actually executed by the VM. For most performance analysis cases, this
is a desired feature. As the calls within the Java application are eliminated, the
corresponding calls to the profiler are eliminated too, resulting in lower
profiling overhead. The count of created objects cannot be reliably estimated
from the call graph in the presence of inlining, because the calls to the
constructors may have been inlined.
The default value for this option is enable.
Another way to disable inlining is to collect the profile data while running
the VM in interpreted mode (-Xint). | times=quick|thorough times=quick|strict | (in JDK 1.4.x, PA-RISC 1.1 version only) The quick
value instructs the profiler to use the hardware Interval Timer register for
time measurement. This value results in faster profiling runs, but in extremely
rare circumstances can produce bad data. This is the default. If you ever
suspect that the profile data generated using the quick value is incorrect,
re-run to see whether the results can be replicated. The thorough/strict
value is the opposite of quick, and disables the use of the Interval Timer.
The profiling runs will be longer, and will provide timing data with the same
(relatively poor) quality as the system calls used to measure the time. The
profiling intrusion and overhead will also increase. Do not specify this option
unless you know what you are doing. The collected profile data will be almost
certainly have less accuracy than when collected using the quick value. | | ie=yes|no | Enable/disable the profiling intrusion estimation. ie=yes,
the default value, specifies that the profiler estimates the profiling intrusion
and writes the estimated values to the profile data file. HPjmeter uses this
data to compensate for intrusion, which means that the estimated intrusion
is subtracted from the CPU times before they are presented to the user. Disabling
intrusion estimation slightly reduces the size of the data files, but will
also disable the intrusion compensation feature. This option has no impact
on the actual profiling overhead. |
Profiling with Zero Preparation | |
Zero preparation profiling is a feature of the HP JDK/JRE 5.0.04. It
is started from the command line by sending a signal to the JVM to start eprof.
Engaging zero preparation profiling may have a short term impact on application
performance as the JVM adjusts to the demands of performing dynamic measurements. To collect profiling data without interrupting your application, do
the following from the command line: Confirm that a HP JDK/JRE 5.0.04 or later is running the application
that you want to profile, and that no -Xeprof option has
been specified. Find the process ID of the running Java application. Start the profiling interval: send a signal to the JVM by
typing: kill -USR2 pid You will see the following message: eprof: starting profiling Let the profiling collection generated by the JVM continue for the length
of time that you think will be meaningful. Stop the profiling interval by sending the same signal to
the JVM: kill -USR2 pid You will see the following message: eprof: terminating profiling writing profile data to ./filename.eprof You can now open the saved file in the HPjmeter console and view the
collected metrics.
| | | | | NOTE: For the signal to be captured by the JVM, you must either be logged
in as root, or you must be the user who started the JVM. | | | | |
Profiling with -agentlib:hprof | |
Java 2 introduced a profiling interface, called JVMPI (Java Virtual
Machine Profiler Interface). The interface comes with a sample profiling agent,
called hprof. Any VM that supports JVMPI should be also
able to run hprof. This agent creates profile data files that can be interpreted after
the program terminates. However, note that the format of the files may be
still evolving. Most Java versions based on JavaSoft implementations are compatible. To run your application with profiling, use the
following command: java ... -agentlib:hprof[=options] ApplicationClassName |
To profile an applet, use the following command: appletviewer ... -J-agentlib:hprof[=options] URL |
The following options are useful: For performance profiling: cpu=samples,thread=y,depth=10,cutoff=0,format=a If you must have method call counts for performance profiling: cpu=times,thread=y,cutoff=0,format=a For analyzing object allocations: heap=sites,cpu=samples,thread=y,cutoff=0,format=a For solving memory retention problems ("memory leaks"): heap=all,thread=y,cutoff=0,format=a,doe=n Then use kill -QUIT pid (on
UNIX ) to get the heap dump.
To see the complete list of available options, use java ... -agentlib:hprof=help To see the availability of HPjmeter metrics from hprof data
collection, see –Xeprof and –agentlib:hprof Profiling Options and Their
Corresponding Metrics. Here are the supported -agentlib:hprof options that
affect the collection of profile data: Table 5-2 Supported -agentlib:hprof options | heap=dump|sites|all | The heap dump shows all objects remaining in memory at the time
of the dump. The allocation sites show where the objects were created during
the execution of the program. Heap analysis can be used to locate memory leaks,
and the allocation sites can be used to minimize the memory usage. To
solve memory retention problems, the best practice is to use a signal rather
than the application shutdown to obtain the heap dump. When the application
shuts down, some references go out of scope and the
retention problem may get eliminated just before the heap is dumped. Send
the signal at the moment that you suspect the application is holding references
to no longer needed objects. To keep the heap dump size down,
try to send the signal just after a full garbage collection (use -verbose:gc to
be notified about the garbage collections). Remember that a heap
dump contains all objects, not just live objects | | cpu=samples|times|old | cpu=samples uses sampling as the collecting
technique, while cpu=times and cpu=old use
tracing with reduction. Typically, the times collected by cpu=samples|times are CPU
virtual times. However, HP-UX 11i versions use real CPU times
rather than CPU virtual times unless sampling is used. The times collected by cpu=old should be
clock times, but some implementations report CPU virtual times. Some implementations
of cpu=times report clock time. HPjmeter tries to
figure out what times actually have been collected, but sometimes does not
do it right. cpu=old outputs inclusive method times, while cpu=samples and cpu=times output
exclusive times. cpu=old cannot
produce profiling data separately for each thread. Collecting heap data can be very intrusive, so we recommend
that you measure the method times and heap usage at different times. However,
it may make sense to specify heap=sites and cpu=samples|times for
the same run when you want to find the allocation sites in the call graph.
| | thread=y|n | Controls whether the stack traces collected during program execution
will be associated with an individual thread. By default, no thread identification information is stored
(thread=n). If you do not use cpu=old, we suggest that
you always specify thread=y. With the thread identification in the profile file, HPjmeter can
calculate the thread profile data for the entire application.
| | depth=size | Controls the depth of the stack trace for each stack trace taken. Increasing this value will make the profile data file larger,
but it enables HPjmeter to better estimate inclusive method times and generate
more complete call graphs. If you measure application performance by sampling, the default
value of 4 is too small for most applications; use values between 6 and 12.
| | cutoff=value | This is the cut-off value for printing the list of methods with
their exclusive times or object allocation sites. Decreasing this value will make the profile data file slightly
larger, but it enables HPjmeter to produce more complete call graphs or heap
metrics. Use a value of 0 for all applications.
| | format=a | HPjmeter supports only the ASCII format of the profile file. | | | | | NOTE: Note that hprof does not list method arguments. In
effect, all overloaded methods are represented as just one method. | | | | |
|
Naming Profile Data Files | |
The following table shows the file name formats used by default when
naming files containing profiling data. You may want to follow this convention
when naming profile data files, but it is not required. Table 5-3 Default File Name Suffixes for Profile Data | Profiling Option | File Name Suffix |
|---|
| -Xeprof | .eprof | | -agentlib:hprof | .hprof.txt |
For other file suffixes recognized by HPjmeter, see Naming Monitoring Data Files |
Printable version
