VisualVM is a powerful graphical tool that comes with the HotSpot JVM. It has a number of views, which can be useful for diagnosing performance problems with SOA Suite. This recipe looks at a number of these features.
You will need SOA Suite installed for this recipe, and will need permission to execute the domain control scripts, as well as the JVM tools. This recipe assumes that your SOA Suite application is running under a normal load, or a load sufficient to demonstrate any performance problems.
The tool jvisualvm is included with the HotSpot JVM, JRockit has a different tool described in a different recipe. For brevity, this recipe assumes that you have the relevant JVM bin directory on your path. If you do not, simply use the fully qualified paths to the relevant bin directory.
Use JPS to determine the process ID of your SOA Suite server, see step 1 of the Identifying New Size Problems with jstat recipe. This will let us identify a target Java process in a host running multiple JVMs. We're trying to identify the WebLogic admin server to use with Visual VM.
Start VisualVM by using the
jvisualvmcommand:jvisualvm
If this is the first time you have run VisualVM, it will first perform calibration on your server. Once the calibration is completed, the VisualVM homepage will open as shown:
Select the WebLogic process that has the process ID you identified in step 1. Either double-click on it, or right-click and select Open.
VisualVM will open the Overview page for the WebLogic Server instance. You should check that the server name matches the one you were expecting.
Switch to the Monitor tab, which provides an overview of the performance of the application.
There are a number of things that we want to check on this tab:
VisualVM contains two profilers that can be used to identify performance problems. We prefer to use the sampling profiler, which is available on the Sampler tab.
Click on the CPU button to begin profiling your application. The table will show which Java methods are taking the most time.
VisualVM hooks into the JVM to read the statistics about memory usage, garbage collection, and other internals, and displays them graphically for the user. Many of these metrics are useful in identifying where a performance problem lies.
An application with high CPU usage may be CPU bound, but before just putting it on a host with more or faster CPUs, we need to identify what it is that is using the CPU. Garbage collection is a common culprit, so the graph showing the amount of CPU time spent running the garbage collector is particularly useful. If garbage collection is not the culprit, then the sampling profiler will show us where the CPU time is being spent. This is essentially a graphical version of using the jstat and jstack tools mentioned in other recipes.