HP

HPjmeter 4.1 User's Guide

English
  HPjmeter 4.1 User's Guide > Chapter 5 Profiling Applications   

Collecting Profile Data

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=integerSpecifies 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|sigusr2Specifies 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=filenameThe 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|enableThe 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).
ie=yes|noEnable/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:

  1. 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.

  2. Find the process ID of the running Java application.

  3. 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.

  4. 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). This interface came with a sample profiling agent, called hprof.

The Java 5.0 release introduced an improved profiling interface, called JVMTI (Java Virtual Machine Tool Interface), which replaces JVMPI. The hprof agent is also available with JVMTI.

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. Currently HPjmeter can read text and binary files.

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.

NOTE: Beginning with HPjmeter version 3.1, you can view binary hprof files (format=b) in HPjmeter visualizers.

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. For additional information on collecting heap dump data, see (http://h18012.www1.hp.com/java/support/support_guide.html).

NOTE:

With the addition of JVMTI in JDK 5.0, the -agentlib switch is the preferred way to activate tools such as hprof. With -agentlib, you can take advantage of improvements in JDK 5.0 and reduce the impact of data sampling on application performance. While -Xrunhprof can still be used to specify the JVM agent with Java 5 versions, the impact on application performance is significantly greater than when using -agentlib.

You will still need to use -Xrunhprof to specify the hprof agent for earlier supported versions of Java (1.4.x).

Here are the supported -agentlib:hprof options that affect the collection of profile data:

Table 5-2 Supported -agentlib:hprof options

heap=dump|sites|allThe 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 uses 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.

  • 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=samples and cpu=times output exclusive times.

  • 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 locate the allocation sites in the call graph.

thread=y|nControls 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).

  • 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=sizeControls 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=valueThis 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 ,format=b HPjmeter displays both ASCII and binary 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 OptionFile Name Suffix
-Xeprof.eprof
-agentlib:hprof.hprof.txt

 

For other file suffixes recognized by HPjmeter, see Naming Monitoring Data Files