|
|
The Oracle JRockit JVM is designed to run in large server environments. Because of that, the JVM needs to provide constant, even performance throughout an application run. Occasionally, you might find that this performance begins to slip the longer the JVM runs. For example, your application works fine early in its run but, after a while it starts to run slower and show an unstable performance. This section provides information on how to recognize and address performance degradation.
When system performance begins to falter the problem is often with tuning. Incorrectly tuned compaction may for example cause the performance to degrade periodically as the fragmentation on the heap increases until the garbage collector must perform a full compaction in order to avoid throwing an OutOfMemoryError.
Before engaging in time-consuming troubleshooting and mitigation tasks, you should tune the JRockit JVM for stable performance and restart the application. For detailed instructions on how to tune the JVM for stable performance, please refer to Tuning For Stable Performance.
Occasionally, when you encounter increasingly poor performance, you might be experiencing optimization problems. These problems tend to show up after the program has been running fine for a while and usually result in something like the following happening:
NullPointerExceptions get thrown from unexpected points in the program.
Generally, optimization won’t cause the sort of problems that you are experiencing with poor performance; however, before you report the issue, you can run the JVM with -XnoOpt enable to turn off code optimization just to eliminate this as a possible cause of the problem. If the application runs properly after turning off optimization, you can assume the problem was there. You should then follow the procedures for isolating and excluding the mis-optimizing method described in Exclude the Offending Method.
A memory leak in Java causes the application to run slower and slower over time, as the garbage collector will have to work harder to free memory. In the end the JVM will throw an OutOfMemoryError, but applications with a small memory leak can sometimes run for days until that happens.
To look for initial signs of a memory leak you can do a JRA recording and check the heap usage after each old collection. If this memory usage keeps increasing you may be looking at a memory leak. If you are running the JRockit JVM R27.1 or higher with Oracle JRockit Mission Control 2.0 or later, complete instructions for creating and interpreting a JRA recording are available from the JRockit Mission Control built-in help. If you are using an earlier version of the Oracle JRockit JVM, please refer to Creating a JRA Recording with JRockit Mission Control 1.0 for these instructions.
You can diagnose memory leaks using the Memory Leak Detector, which will help you pinpoint the class that causes the memory leak. Complete instructions for using the Memory Leak Detector are available in the built-in help in Oracle JRockit Mission Control 2.0 and later releases.
If none of the tuning solutions suggested in Tuning For Stable Performance resolve the problem, you will need to open a case with Oracle Support. You can find instructions on how to report a problem to Oracle, including the sort of information to include, in Submitting Problems to Oracle Support
|