6 Tuning WebLogic Diagnostic Framework and JRockit Flight Recorder Integration

This chapter provides information on how to tune WLDF integration with JRockit Mission Control Flight Recorder in WebLogic Server 10.3.6. WebLogic Diagnostic Framework (WLDF) provides specific integration points with JRockit Mission Control Flight Recorder. WebLogic Server events are propagated to the Flight Recorder for inclusion in a common data set for runtime or post-incident analysis. See "Using WLDF with Oracle JRockit Flight Recorder" in Configuring and Using the Diagnostics Framework for Oracle WebLogic Server.

This chapter includes the following topics:

Using JRockit Flight Recorder

The version of Oracle JRockit that is provided with WebLogic Server includes a component called JRockit Flight Recorder (JFR), a performance monitoring and profiling tool that provides configuration options for controlling the events generated by the JVM. For more information about JFR, see "Introduction to the Flight Recorder" in Oracle JRockit JRockit Flight Recorder Run Time Guide.

You can enable JFR at runtime to take JRA recordings from the JRockit Management Console. You also have the option of turning off the JFR and recordings at the JRockit JVM level from the java command line using:

$ java -XX:-FlightRecorder

Note:

If you use the -XX:-FlightRecorder option to disable JFR, it disables all JRA support, including the ability to turn on JRA at runtime.

Using WLDF

WLDF provides the Diagnostic Volume attribute to set the amount of code coverage that is enabled and the amount of data provided in the events that are generated for the covered code. The volume can be adjusted using the WebLogic Console, see "Configure WLDF diagnostic volume" in Oracle WebLogic Server Administration Console Help. You can also set the volume using WLST. The following code example sets the volume to Medium:

. . .
connect()
edit()
startEdit()
cd("Servers/myserver")
cd("ServerDiagnosticConfig")
cd("myserver")
cmo.setWLDFDiagnosticVolume("Medium")
save()
activate()
. . .

JRockit and WLDF generate global events that contain information about the recording settings even when disabled. For example, JVM Metadata events list active recordings and WLDF GlobalInformationEvents list the domain, server, machine, and volume level. You can use WLDF Image capture to capture JFR recordings along with other component information from WebLogic Server, such as configuration.

The Diagnostic Volume setting does not affect explicitly configured diagnostic modules. By default, the Diagnostic Volume is set to Low. By default the JRockit default recording is also Off. Setting the WLDF volume to Low or higher enables WLDF event generation and the JVM events which would have been included by default if the JRockit default recording were enabled separately. So if you turn the WLDF volume to Low, Medium, or High, you get WLDF events and JVM events recorded in the JFR, there is no need to separately enable the JRockit default recording.

Using JRockit controls outside of WLDF to control the default JVM recording

You can enable the JVM default recording (or another recording) and continue to generate JVM events regardless of the WLDF volume setting. This allows you to continue to generate JVM events when WLDF events are off.

Tuning Considerations

In most environments, there is little performance impact when the Diagnostic Volume is set to Low and the most performance impact if Diagnostic Volume is set to High. The volume of diagnostic data produced by WebLogic Server needs to be weighed against potential performance loss.

Note:

There is a known issue that can cause a potentially large set of JVM events to be generated when WLDF captures the JFR data to the image capture. The events generated are at the same timestamp as the WLDF image capture and are mostly large numbers of JIT compilation events. With the default JFR and WLDF settings, these events are seen only during the WLDF image capture can be ignored. The expectation is that the VM events generating during Diagnostic Image capture should have little performance impact, as they are generated in a short window and are disabled during normal operation.