Recorded data includes profiling of methods and locks, as well as garbage collection statistics, optimization decisions, and, in JRockit Mission Control 3. To start the diagnostics process, Fiona does the following:. Next, Fiona creates a JRA recording from a local connection. To do so, Fiona does the following:. The JRA recording progress window appears.
When the recording is finished, it loads in the JRA. Fiona will now look at the JRA Recording. First, she opens the General tab by doing the following:. The JRA General tab for that recorded file now opens, allowing Fiona to view the data in the recording. The General tab contains information on the JVM, your system and your application.
It is divided into the panels described in Table :. VM Arguments Lists all startup options that were used. Allocation Contains information on how your application allocates memory on the Java heap.
Threads Contains information on thread usage. Exceptions Contains exceptions related information. By looking at this tab, Fiona is able to verify which version of the JVM she was running. Next, Fiona will look at the Methods tab. The Method tab lists the top hot methods with their predecessors and successors during the recording. The Methods tab is divided into the following panels described in Table :.
The Top Hot Methods section lists all methods sampled during the recording and sorts them with the most sampled method s first, as shown in Figure By looking at the list of top hot methods, Fiona sees that the three hottest methods are:.
Starting with this information, Fiona has a good idea of where to start looking for possible areas of concern. Fiona knows that the hottest methods are those that are sampled most often. In some situations, the number of samplings in the hottest methods will dwarf those of the less-hot methods.
Hot methods are a good indicator of performance problems, especially memory leaks, because the high amount of sampling affects how much time the JVM has been executing the specific method.
This tab is divided into the six panels described in Table Looking at the data in the Garbage Collections panel Figure , Fiona sees that the three longest garbage collection pause times are indexed 95 ms , 41 ms , and 73 ms. This data implied that, as processing continued on her application, garbage collections were taking longer. She sees that garbage collection times are increasing, particularly later during runtime, and that the garbage collections are freeing less space on the heap.
She can, with some confidence, predict that she is experiencing a memory leak. Fiona can gain more insight into how garbage collection activity might be indicating a memory leak by looking at the GC General tab Figure This tab is divided into three panels that provide information about the garbage collection at a glance.
This tab is divided into the panels described in Table :. Fiona expands the stack tree down to user code and sees that many allocations are from the hashtable type, which indicates that this type is allocation intense. Reducing the allocation of this type would probably reduce the pressure on the memory management system. Next, Fiona decides that it would be helpful to compare object statistics collected at the beginning of the recording to those collected after the recording.
At the beginning and at the end of a recording session, snapshots are taken of the most common types and classes of object types that occupy the Java heap; that is, the types of which the total number of instances occupy the most memory. The results are shown on the Objects tab Figure The Object Statistics tab is divided into the panels described in Table Fiona can again see that hashtable shows the most dramatic growth and is consuming the greatest amount of memory on the heap.
This again is a strong indication of not only a memory leak but that said leak involves the hashtable object. Fiona then checks the lock statistics for clues to performance bottlenecks involving locks. The Lock Profiling tab is divided into the panels defined in Table By looking at the Java Locks panel, Fiona can see immediately that the hashtable type has taken over million uncontended locks, compared to a relative few for other objects.
While this information does not point directly to a memory leak, it is indicative of poor performance. Since the lock is mostly uncontended, Fiona could optimize her application by switching to an unsynchronized data structure such as hashmap and provide synchronization only for the few cases where contention may occur. Since Fiona determined that a memory leak is causing her application to run poorly, she can take advantage of the JRockit Memory Leak Detector to confirm her suspicions and begin corrective action.
A memory leak occurs when a program fails to release memory that is no longer needed. The term is actually a misnomer, since memory is not physically lost from the computer. Rather, memory is allocated to a program, and that program subsequently loses the ability to access it due to program logic flaws. To start the memory leak detection process, Fiona does the following:. Fiona starts the analysis from the Trend tab Figure , which should open when she launches the Memory Leak Detector.
The trend analysis page shows Fiona the statistics on memory usage trends for the object types within the application. The JVM collects this data during garbage collections, which means that at least two garbage collections must be done before any trends are shown.
Fiona finds that a class named DemoObject shows the largest growth. This opens the Types tab Figure Here Fiona can see that the DemoObjects are stored in hashtable entries. Now Fiona can see that the DemoObjects are indeed stored in hashtable entries. The next step for Fiona is to find out more about the instances holding on to the hashtable entries containing these DemoObjects.
Not all hashtable entries in the application point to the same type of objects, so Fiona gets a popup that asks her to select the type of references she is interested in. At the bottom of the Types tab Fiona gets a list of instances of java. This opens the Instances tab, as seen in Figure Fiona finds that the DemoObject is stored in a hashtable, which is held by a DemoThread. This is the culprit causing the memory leak. Judging from the evidence she collected using the Oracle JRockit Mission Control tools, Fiona was able to not only identify her system problem as a memory leak, but was able to locate exactly which object type was leaking the memory.
The key to making the identification began with noting in her JRA recording the increasing length of garbage collections and the types upon which those lengthening garbage collections were occurring. Please note that this can affect applications running in the JVM. In versions prior to 3. If you are using an earlier version of the product, ensure that method profiling was enabled for your JRA recording and that the application was under load.
If the JRockit JVM is spending most of the time with none of the threads doing any work, no samples will be recorded. If you still want to create a JRA recording with method sampling and a low load, try increasing the sampling frequency. The algorithm needs at least three data points to kick in and the data is collected as part of the old space mark phase of the garbage collection. If you see no data, possibly not enough garbage has been collected for these collections to occur.
To speed up the process, try clicking the garbage can in the toolbar of the Memory Leak application to force three successive garbage collections, with a brief pause in between each collection.
You are entitled to support if you have an Enterprise licence. If you have any questions you are welcome to share them in the Oracle JRockit forum, which is monitored by the Oracle JRockit engineering team. To access the news group, go to:. Typical information that is recorded during a JRA recording is Java heap distribution, garbage collections, method samples, and lock profiling information optional.
Typical data that you can view is thread usage, CPU usage, and memory usage. All graphs are configurable and you can both add your own attributes and redefine their respective labels.
From these MBeans, you can read attribute information, such as garbage collection pause times. If this directory is on your system path, you can start the JRockit Mission Control Client by simply typing jrmc in a command shell prompt. Otherwise, you have to type the full path to the executable file, as shown below:.
From the JRockit Browser you activate different tools, such as starting a JRA recording, connecting a Management Console, and starting memory leak detection.
0コメント