Chat now with support
Chat mit Support

Foglight for Java EE Technologies 5.9.10 - Application Servers User Guide

Monitoring Application Servers Monitoring Systems Monitoring Servers Monitoring Deployed Applications Monitoring Requests Managing Traces Using Object Tracking to Locate Memory Leaks Monitoring Methods Application Servers Monitor Views
JVM view Method Groups view Request Types view Entity EJBs view Message Driven EJBs view Stateful Session EJBs view Stateless Session EJBs view Deployed Applications view JSPs/Servlets components view Resource Adapters components view Web Applications components view Web Services components view .NET views JBoss Services views Oracle Services views Tomcat Services views WebLogic Services views WebSphere Services views JMX Administration dashboard JMX Explorer dashboard
Appendix: Regular Expressions

Selecting a trace to baseline or compare metrics

The Select trace to baseline or compare feature can display the relative performance of a single trace as compared to another single or aggregate trace. Selecting a baseline trace adds columns and fields that show the difference (DIFF) between the currently viewed single trace and the selected baseline trace.
To select an aggregated trace as baseline:
1
On the navigation panel, under Dashboards, click Application Servers > Monitor.
2
On the Application Servers Monitor dashboard, click the Requests tile.
3
On the Requests view, click the value in the Traces column for the request you want to investigate.
The Traces View opens.
4
In the Traces view, click the name of a single trace.
The Trace Diagnosis view opens.
5
Select either the Method List tab or the Call Tree tab.
6
Select a method.
7
Click the edit icon beside the text Select trace to baseline or compare.
8
In the menu that opens, click Select an aggregated trace as a baseline.
9
In the Select Trace for Comparison Dialog — Aggregated dialog box, click an aggregated trace to use as a baseline for comparison.
The view updates with the message: “Comparing to trace at: <time stamp>”.
The Method List and Call Tree tables now include a DIFF column, which compares the Total Execution Time and the Average Exclusive Time. A DIFF column also appears for the Execution and Exclusion times in the Exceptions and Incomplete table, on the bottom right of the view.
To set a single trace to compare metrics against:
1
Perform step 4 through step 7 in the previous procedure.
2
Click Select a single trace to compare.
3
In the Select Trace for Comparison Dialog — Single dialog box, click a single trace to compare.
The view updates with the message: “Comparing to trace at: <time stamp>”.
The Method List and Call Tree tables now include a DIFF column, which compares the Total Execution Time and the Average Exclusive Time. A DIFF column also appears for the Execution and Exclusion times in the Exceptions and Incomplete table, on the bottom right of the view.
To clear the selection:
1
Click the Edit icon.
2
Click Clear selection.
 

Using Object Tracking to Locate Memory Leaks

Foglight for Java EE Technologies includes the ability to examine monitored class breakdowns of tracked objects for each application server that participated in a request. You can use the breakdowns to investigate why memory usage problems are occurring for a particular application server.
Over the runtime of an application, objects that are allocated memory in the Java Virtual Machine (JVM) heap become eligible for garbage collection once all references to them have been released. If object references are not released, the objects loiter in memory taking up space that could be reused.
To examine these memory leak problems, you can enable object tracking and review the root of the problem.
 
* 
NOTE: Object tracking is off by default. Enabling object tracking may cause added overhead on the performance of your application server. Also note, increasing the LiveObjectLifeSpan agent property value increases memory requirements of the agent. For more information about this agent property, see Updating object tracking agent properties .
Typically several application servers can be used to service a request and this request can cross JVM boundaries. On each JVM, memory is allocated for each application running. When monitoring your JVMs, you may notice a change in the memory performance for all your JVMs. In this situation, you can investigate the memory leak on one JVM first and then narrow down the investigation to find the application causing the leak. Once you have the memory leak source identified, you can then change the code to improve memory allocation for that application to resolve the leak.
Understanding when memory usage problems occur
You may observe a generally and consistently upward trend in the memory usage of a monitored JVM. For example, this occurs when object instances are added to a persistent, pinned collection but due to a coding error they are never removed. In this case, use object tracking to detect the object instances that are allocated but not collected.
In some situations, although memory usage appears normal, an excessive number of garbage collections may occur. The Foglight Management Server runs garbage collection rules to check on the time spent on garbage collection and if it exceeds a pre-defined threshold, alarms are generated. Excessive garbage collection may happen when allocating unnecessary or redundant object instances in a frequently used code path. While not a leak, this can still be a performance problem due to the garbage collection algorithm using more CPU time than would otherwise be necessary from the applications. In this case, object tracking can detect the most frequently allocated classes, regardless of whether they are collected.
The next step in both of these cases is to look more closely at object allocations in the affected JVM.
Workflow for enabling object tracking to detect general memory problems:
1
Updating object tracking agent properties
2
Enabling object tracking
3
Examining object tracking data

Updating object tracking agent properties

Object tracking applies to Foglight for Java EE Technologies only. To use object tracking, specify the packages and classes that you want to monitor in the agent configuration property file. The intention is that object tracking configuration should be changed infrequently. For example, you may change the configuration to include the packages of newly deployed applications that you want to monitor using object tracking.
By default, object tracking is configured such that the Java utility collection classes can be tracked. This may be sufficient for an initial investigation, however, to track objects allocated in your applications, add or replace the default configuration with your own packages.
Configuring object tracking does not enable object tracking; it only specifies what is tracked when you do enable object tracking.
 
* 
NOTE: Restart your application servers after changing the object tracking classes in the configuration in order for the changes to take effect.
To update object tracking agent properties:
1
On the navigation panel, under Dashboards, click Application Servers > Administration.
2
On the Application Servers Administration dashboard, click the Java tab.
3
On the Java Administration dashboard, click the Agent Configuration tab.
4
Click the name of the agent profile that you want to edit (for example, Default Java).
5
In the menu that opens, select Edit instrumentation settings.
The Configuration Category Editor opens.
6
Click the Object Tracking tab.
7
Click the edit icon to the right of ObjectTrackerClasses to update the list of classes being included or excluded.
For example, if you are only interested in tracking classes within the following two packages, com.quest.pkg1. and com.quest.pkg2., do the following:
a
In the Settings Editor dialog box, click Add. A blank row is added to the bottom of the list.
b
Scroll down to the empty row.
c
Click in the Class Name box of the empty row, and type the following: com.quest.pkg1.
d
Click Add again.
e
In the new blank box, type: com.quest.pkg2.
f
Optional — If you want the class name to be interpreted as a regular expression (regex) instead of a literal string, click the check boxes beside the rows you added.
g
Click OK. The new entries are added to the ObjectTrackerClasses list in the Configuration Category Editor dialog box.
 
* 
IMPORTANT: These settings are valid when the Instrumentation Level is set to FullDetail or ComponentDetail. Changing their values has no effect if the Instrumentation Level is set to BasicDetail or NoDetail.
8
Click Save.
9
Optional — Edit the Nexus recording settings to set the maximum amount of time that the agent tracks a live object (that is, the LiveObjectLifespanLimit). By default, the LiveObjectLifespanLimit is set to 900 seconds.
•
Increasing this value gives the garbage collector more opportunity to collect live objects before the agent marks them as expired, but uses more memory in the application server process.
•
Decreasing this value makes it more likely that the agent expires the live objects before they are collected, but uses less memory.
For more information, see Calculating the LiveObjectLifespanLimit value .
For detailed information about the Nexus recording settings, see the Managing Nexus Recording Settings section in the Foglight for Application Servers Administration and Configuration Guide.
10
Optional — Edit the Nexus recording settings to set the maximum number of live objects that the agent tracks. By default, the LiveObjectCountLimit is set to 524288.
•
Increasing this value allows the agent to track more live objects concurrently, but uses more memory in the application server process.
•
Decreasing this value makes it more likely that the agent expires the live object before it is collected, but uses less memory.
For detailed information about the Nexus recording settings, see the Managing Nexus Recording Settings section in the Foglight for Application Servers Administration and Configuration Guide.
11
Restart your application server.
Calculating the LiveObjectLifespanLimit value
Foglight for Java EE Technologies provides a suggested lifespan value for the agent to track a live object before marking it as expired. Depending on the complexity of your application along with your JVM heap settings and resulting garbage collection rate, the default value of 900 seconds (15 minutes) may not be appropriate.
An appropriate value for the LiveObjectLifespanLimit property can be derived from your observations of the time between the major garbage collections taking place. If the LiveObjectLifespanLimit is shorter than the time between major garbage collections, the agent may be prematurely marking objects as expired.
If you are able to have object tracking use additional memory, you may want to increase the LiveObjectLifespanLimit value to span the interval between major garbage collections. However, keep in mind that increasing this value does require additional memory within the application server heap.
Next step:
•
Enabling object tracking

Enabling object tracking

Prerequisite:
•
Updating object tracking agent properties
After you have set the required agent properties, enable object tracking for Foglight for Java EE Technologies.
To enable object tracking:
1
On the navigation panel, under Dashboards, click Application Servers > Monitor.
2
Click the Servers tile and select a server.
3
In the server details view, click JVM (not the status icon).
4
In the Java Virtual Machine (JVM) view, click the Object Tracking tab.
5
Do one of the following:
•
Click Enable Object Tracking.
Select the length of time (duration) to enable object tracking.
or
•
Select one or more classes from the list, then click Track Per Request Type.
Select Enable.
Next step:
•
Examining object tracking data
Verwandte Dokumente

The document was helpful.

Bewertung auswählen

I easily found the information I needed.

Bewertung auswählen