|
|
United States-English | |
|
|
 |
|
HPjmeter Version 3.1 User's Guide > Chapter 8 Using Visualizer Functions
Using Monitoring Displays |
|
|
Monitoring metric displays are available from the Monitor menu on the main console. The monitoring displays can be used during live operation of the application and with saved data files. HPjmeter monitoring metrics are organized as follows: Monitor Code and/or CPU Activity Menu Monitor Memory and/or Heap Activity Menu “Monitor Threads and/or Locks Menu” Monitor JVM and/or System Activity Menu Displays a sampling-based estimate of the CPU time consumed by individual Java methods. Methods are listed from highest to lowest CPU usage by percentage; over a session lifetime; with package, method, and method arguments displayed. Each method's information is written over a graphical representation of the confidence interval calculated for that method. Figure 8-3 Monitoring Metric: Java Methods HotSpots with Confidence Interval Graphically Displayed for Each Method
You can turn off the display of package and argument information from the View menu. HPjmeter reports select methods that are the root cause of high CPU-time usage, while excluding others that are rarely relevant. This technique reports methods that are most likely to need additional optimization. A common optimization technique is to improve how a method calls helper methods. These helper methods are not included in the list. The percentages are not absolute across the entire application, but are computed only with respect to the methods HPjmeter reports. HPjmeter does not report small methods, which are frequently inlined, and methods outside your application, such as those in the java.* package. The goal is to help you zoom in on your core application logic, including use of helper methods and APIs. The metric window reports “No hotspot detected at this time” until it detects a Method CPU hot spot, and then the metric data appears. The survey for hot spots often takes just a few seconds, but in some cases could take longer. Displays thrown exception counts according to the exception type and the catching method. If you need stack trace information, refer to Thrown Exceptions with Stack Traces. The integer is a count of how many times this exception has been thrown in this location, and caught by this method. The percentage gives information on how often this exception is being thrown in relation to all the detected thrown exceptions. HPjmeter collects and reports exceptions caught in classes that are instrumented, that is, classes that the JVM agent instrumentation rules have not excluded. To identify the JVM agent rules in effect, you can use the JVM agent verbose option. HPjmeter does not collect or report exceptions that are caught in methods filtered out by the exclude JVM agent option. The display shows “No thrown exception detected since the session opened.” until HPjmeter detects a thrown exception, at which time it displays the information. The window shows events in a hierarchical tree. The View menu allows you to control the information displayed in the window:
The results are cumulative over the lifetime of the session. Related topics
Enable this metric in the Session Preferences
window only when you need to get information about where your applications
throws exceptions. To view this data, click Monitor Collecting the stack trace information could impair the performance of your application if the application throws a large number of exceptions during the session. To minimize the effect on your application, you can enable the Thrown Exceptions metric when you start your session, which does not collect stack traces. For details, see Thrown Exceptions. This metric displays thrown exception counts according to the exception type, the catching method, and the stack trace of the throwing location. The integer is a count of how many times this exception has been thrown in this location, and caught by this method. The percentage gives information on how often this exception is being thrown in relation to all the detected thrown exceptions. HPjmeter collects and reports exceptions caught in classes that are instrumented, that is, classes that the JVM agent instrumentation rules have not excluded. To identify the JVM agent rules in effect, you can use the JVM agent verbose option. HPjmeter does not collect or report exceptions that are caught in methods filtered out by the exclude JVM agent option. The display shows “No thrown exception detected since the session opened.” until HPjmeter detects a thrown exception at which time it displays the information. The window shows events in a hierarchical tree. The View menu allows you to control the information displayed in the window:
The results are cumulative over the lifetime of the session. Related topics
Displays free and used memory sizes in the heap and garbage collection events over time. The used heap space includes live objects and dead objects that have not yet been collected as garbage. Specifically, this visualizer shows the heap in use by objects in the eden space and in the old and survivor generations, but does not include the permanent generation. (See “Basic Garbage Collection Concepts” if you are unfamiliar with these terms.) This display indicates whether your application is doing many allocations, which typically correspond to the load level, or if your application is idle.
Displays garbage collection events over the period that the application has been running and an estimated percentage of time spent in garbage collection. These events include collection from the young, old, and survivor objects in the heap. This display does not include objects in the permanent generation space. (See “Basic Garbage Collection Concepts” if you are unfamiliar with these terms.) When running your application with Java 5.0.12 or later or with Java 6.0.01 or later, the visualizer can show major versus minor garbage collections.
Each point on the graph represents the heap size after a garbage collection completes; it represents the amount of live memory at that time. Frequent long garbage collections represent a potential problem, and will be coupled with a high percentage of time spent in garbage collection. This percentage is displayed in the lower right of the window. Related Topics
The percentage is an estimated value of the time spent in garbage collection. Here are two possible ways to make improvements:
Related Topics
Shows object allocation statistics according to the object type allocated. A typical large Java application allocates a lot of strings. This value can reach 25 percent of all allocations. If any other type, especially an application-defined type approaches or exceeds such a value, it may indicate inefficient code. For those classes that are instrumented (visible through the JVM agent verbose flag), every object allocation in every method is instrumented to report allocations. However, sampling is used to minimize overhead, so the metric reports allocation percentages, not total allocation counts. These percentages are not absolute across the entire application, but are computed with respect to allocations in instrumented classes. Sampling minimizes overhead and focuses attention on user code. To discover allocation statistics about application server classes, use the include and exclude filtering flags in the JVM agent options. The reported data is cumulative over the lifetime of the session, and accuracy will improve as the session length increases. Related Topics
Shows the methods that allocate the most objects. This metric is useful when you choose to decrease heap pressure by modifying the application code. For those classes that are instrumented (visible through the JVM agent verbose flag), every object allocation in every method is instrumented to report allocations. However, sampling is used to minimize overhead, so the metric reports allocation percentages, not total allocation counts. These percentages are not absolute across the entire application, but are computed with respect to allocations in instrumented classes. Sampling minimizes overhead and focuses attention on user code. To discover allocation statistics about application server classes, use the include and exclude filtering flags in the JVM agent options. The reported data is cumulative over the lifetime of the session, and accuracy will improve as the session length increases. Use this visualizer to obtain an immediate data summary of live objects in the heap each time that you click the Refresh Live Objects button. This can be especially useful when trying to understand unexpected behavior in memory usage. The display shows information for the classes of live objects found. See Table 8-1 Table 8-1 Data Shown in Current Live Heap Objects Visualizer
When the heap is large with many objects, refreshing the snapshot will affect system performance more than refreshing from a smaller heap with fewer objects. Sort by any of the data types by clicking the column header in the Current Live Heap Objects table. Continued clicking toggles the sort between ascending and descending order for numerical columns and by alphabetical order for columns containing text. You can copy all or part of the data displayed into a temporary buffer for export into a spreadsheet or other software. To select a portion of the data, click and drag the cursor across the desired rows and columns of data. The selected rows change color. Then click the Copy to Buffer button in the tool bar to capture the data for exporting into other software formats. Related topics Displays thread states over time. Thread data arrives in time slices. For each time slice, color-coded bars represent the percentage of time the thread spent in each state. The reported states are:
Provides lock contention statistics. The percentages for each method represent how much of the total lock contention observed occurred in that method. For example, if there was a single instance of lock contention during a run, the method would show 100 percent. Therefore, methods that show a high percentage of lock contention may not be a problem, unless you see a significant amount lock contention in your application. Lock contention can be detected either in synchronized methods, or in methods that contain synchronized blocks.
Sampling minimizes overhead, therefore, the display shows percentages of time wasted, not actual time wasted in lock contention. The reported data is cumulative over the lifetime of the session.
Displays a list of all the methods compiled from the time the session was opened, showing the number of times a particular method was compiled. The metric window reports “No methods compiled since the session opened.” until the next method compilation occurs, and then the metric data appears.
Related Topics
HPjmeter displays the number of classes loaded into memory for processing. This number usually stabilizes over time as processing progresses.
Related Topics Displays total system and process CPU consumption.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Printable version |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
Show Percentages to alternatively hide or show the percentage value of the total
count for each exception, shown next to the count value.
