|
|
United States-English | |
|
|
 |
|
HPjmeter Version 3.1 User's Guide > Chapter 8 Using Visualizer Functions
Using Profile Displays |
|
|
Profiling metric displays are available from the Metrics and Estimate menus in the profiling viewer. These visualizers display data collected with -Xeprof and hprof options. Note that the hprof data does not provide both CPU and clock times. The following figure shows a profile viewer as it appears when first opened.
The profile displays are categorized as follows under the Metrics menu:
These heuristic displays appear under the Estimate menu: The menu bar can contain one or more of these choices, depending on the data type and visualizer you are viewing:
This section contains metrics that are derived from other metrics. The derived metrics are marked by an asterisk (*). They are usually less frequently used, as they not always are immediately useful in detecting performance bottlenecks. For each metric that presents the average values per call, only methods called at least twice are taken into account. Use this metric visualizer to see the methods called, the callers of each method, and the cumulative number of calls from each caller. The methods are sorted by decreasing number of calls. Listed to the left of each method is the number of times it was called. By default, the list of methods includes the package in which each one is located. The gray horizontal bars provide a graphical representation of the number of times a method was called. Double-click the method name to see a list of its callers with the cumulative number of calls from each caller. Use this visualizer to see CPU time spent by methods found in the captured data. CPU time spent is given in milliseconds, and for each method, as a percentage of all CPU time used during the capture period. Times are exclusive times. A remark "(virtual times)" may be displayed after the metric title, if the collected times are virtual CPU times. The methods are sorted by decreasing time spent in CPU. The gray horizontal bars provide a graphical representation of the time a method spent (in milliseconds) for the period of the collected sample. Other data shown include packages and arguments associated with each method. The standard Java methods java.lang.Thread.sleep and java.lang.Object.wait are not included in this metric. This is because usually the time spent in these methods is a few orders of magnitude larger than in any other method. At the same time, the total time spent in sleep or wait has hardly any relationship to any possible performance bottlenecks, and including these two methods would only distract the user. A remark “(virtual times)” may be displayed after the metric title, if the collected times are virtual CPU times. To see all callers of a given method with the accumulated inclusive CPU time spent in all calls to this method, double click on the method name. To see all callers of a given method with the accumulated inclusive clock time spent in all calls to this method, double click on the method name. Exclusive CPU Method Time divided by the number of calls to the method. This is the average CPU cost for the body of the method. Exclusive Clock Method Time divided by the number of calls to the method. This is the average time spent within the method. Inclusive CPU Method Time divided by the number of calls to the method. This gives the average CPU cost for a high-level operation. Inclusive Clock Method Time divided by the number of calls to the method. This gives the average turn-around (response) time for a high-level operation. Shows the starvation for each method. For our purposes, starvation is defined as time unaccounted for. During this time, the thread was not suspended by java.lang.Thread.sleep or java.lang.Object.wait, and it was not delayed at the monitor lock entry. The thread was runnable (in the Java sense), yet it was not running; that is, the context had switched out. These are possible reasons for reported starvation:
Shows the starvation (see above) divided by the Exclusive Method Clock Time for each method. Values close to one indicate that the method did not consume CPU, but nevertheless delayed execution of the program. Such methods are worthwhile to investigate to understand the reason of their behavior. This metric tries to locate the most intensive loops in the application. The value is the average number of times a loop within a given method was executed over all invocations of the method. The actual loops are not instrumented (measured), and the calculations are based on the call counts collected for the call graph, so the metric always provides only an estimate. Related Topics The total of the Exclusive Method Times (CPU), summed over all methods of the class. To see the list of all contributing methods, double click on the class name. Related Topics
The total of the Exclusive Method Times (Clock), summed over all methods of the class. To see the list of all contributing methods, double click on the class name. The standard methods java.lang.Thread.sleep and java.lang.Object.wait do not contribute to this metric, however, they will be shown on the list of all contributing methods for the respective classes. Most of the heap metrics are available only for the profiling option -agentlib:hprof=heap=all. See the metrics table to check how to collect the profile data in order to obtain a specific metric. The types of objects allocated on heap are classes and arrays. If the profile data file does not contain the specific information related to objects, HPjmeter estimates Objects Created by Method and Created Objects (Count) based on the number of class constructors called. In such cases, you will see "(data estimated)" next to the metric label. The estimation entirely misses the arrays, and may report inaccurate numbers. Some of the calls to constructors may remain unprofiled, or be not recognized as such by HPjmeter. It is also possible to err on the plus side, when HPjmeter does not properly recognize the class hierarchy. The last three metrics (Reference Graph Tree, Residual Objects (Count), and Residual Objects (Bytes)) show the residual objects. These are objects remaining on the heap at the time the profile data file is written. Number of objects of all types created by each method. Double click on the method name to see the distribution of the number over object types. Related Topics Number of objects of a given type, created by all methods, presented by object types. Double click on the object type to see which methods created the objects. Related Topics Number of bytes occupied by objects of a given type, created by all methods, presented by object types. Double clicking on the type name provides a list of allocation sites (methods) with the number of bytes allocated by each listed method. Related Topics The number of live objects presented by object types. Live objects are those that could be accessed through a chain of references from the set of program variables when the heap dump took place. Related Topics The number of bytes occupied by live objects of a given type, presented by object types. Related Topics The number of objects with pending finalization, arranged by their type and sorted by the number of objects of each type. These are all objects with the finalize()() method available, but not yet invoked. Related Topics Shows all residual live objects and references between them. Expanding the nodes shows which references a given object holds. HPjmeter uses heuristics to detect soft or weak references and uses special symbols ~-> for them, while the hard (regular) references are marked by ->. Double click on an object to view additional information: all references to the object, and the number of bytes held in the heap by this object. This number is the total amount of bytes that could be reclaimed by garbage collection if all references to this object were nullified. This piece of information is sticky - once this value is calculated for an object, it will be displayed in the Reference Graph. Displaying large reference graphs puts a lot of stress on the underlying Swing components, so please be patient when dealing with huge heap dumps. Related Topics The number of residual objects presented by object types. Residual objects are those remaining on the heap while the heap dump occurred. Not all residual objects are live. Related Topics This visualizer shows all threads created by the application. The horizontal bars represent the lifetime of the threads with respect to the lifetime of the whole application. An explanation follows the image.
Use the selections in the Sort menu to change the criteria by which the threads are ordered and presented. See Menu Choices This visualizer presents all thread groups created by the application. The horizontal bars represent the lifetime of the thread groups, with respect to the lifetime of the whole application. The lifetime of the thread group is defined as the time span between the creation of the first thread belonging to the group and the death of the last thread belonging to the group.
The lock delay is a measure for lock contention. The delay is caused by the lock being busy, and is larger if the thread holding the lock is spending much time within the monitor, or when there are many threads attempting to enter the same monitor. Do not confuse lock delay with the time spent in the java.lang.Object.wait() method, or with the time spent by a given thread within a Java monitor. Lock metrics are produced only by the -Xeprof profiling option. Note that the lock metrics do not show individual locks, but only values accumulated over all locks used by a given method. Most methods, however, contain only one synchronization statement or none at all, so identifying the contended lock should be easy if the source code is available. Uncontested locks remain unprofiled for two reasons:
This section contains some metrics derived from other metrics. The derived metrics are marked by an asterisk (*). They are usually less frequently used, as they not always are immediately useful in detecting performance bottlenecks. For each metric that presents the average values per call, only methods called at least twice are taken into account. The following metrics are available. The number of all attempts by individual methods to acquire a Java monitor lock while the lock was being held by another thread, thus entailing a delay, even if only a very short one. Related Topics The number of all Java monitor locks acquisitions by individual methods. The data is inherently incomplete, because the metric is accumulated only since the first lock conflict for each lock. You will see “partial data)” displayed after the metric label. Related Topics Accumulated lock delay, wasted in the method acquiring the lock(s). The lock delay is the time between an attempt to get the lock and the actual acquisition of the lock. Accumulated lock delay, wasted in the method acquiring the lock(s) and all methods called from it and their descendants. Contested Lock Claims divided by All Lock Claims for each method. This gives the average frequency with which the method encountered a taken lock. A method must have claimed a lock at least five times to be included in this metric. Related Topics Method Exclusive Lock Delay divided by the number of calls to the method. For synchronized methods, this is the average delay caused by calling the method. Method Exclusive Lock Delay divided by the Exclusive Clock Time. For each method, this gives the ratio of time wasted on synchronization to the total time spent in the method. Method Inclusive Lock Delay divided by the number of calls to the method. This gives the average delay caused by synchronization for a high-level operation. Method Inclusive Lock Delay divided by the Inclusive Clock Time. For each high-level operation, this gives the ratio of time wasted on synchronization to the total time spent in the operation. The total of the Exclusive Method Lock Delay, summed over all methods of the class. To see the list of all contributing methods, double click on the class name. If a class is used as a monitor with many synchronized methods, the individual methods may not exhibit excessive lock contention, but the problem might get visible using this metric. HPjmeter provides three estimated measures to aid in narrowing the field of your problem-solving or performance tuning inquiry. Use this estimate to see a list of packages, classes, and methods that are possible candidates for inlining activity during processing. For some candidates, the table lists amount of time estimated to be wasted during the execution of the method. Use the Mark button to capture the method name, then use Find in other tabular metric visualizers to locate the method in relation to the other data presented. Related Topics
Use this estimation to obtain a list of methods, packages, and classes and a count of thrown exceptions associated with each method or package. Use the Mark button to capture the method name, then use Find in other tabular metric visualizers to locate the method in relation to the other data presented. Related Topics
Use this estimation to obtain a list of packages and package types where leaks are suspected to be occurring, and the amount of memory associated with each listed package. Use the Mark button to capture the package name, then use Find in other tabular metric visualizers to locate the method in relation to the other data presented. Related Topics
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Printable version |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
