优化Oracle JRockit JVM 虚拟机

Every Java application has its own behavior and its own requirements. The Oracle JRockit JVM can accommodate many of the requirements automatically, but to derive optimal performance, you must tune some basic parameters.

This chapter describes the following initial steps to tune the JRockit JVM and provides some best practices for tuning the JVM for a few different Oracle applications.

• Section 3.1, "Step 1: Basic Tuning"

• Section 3.2, "Step 2: Performance Tuning"

• Section 3.3, "Step 3: Advanced Tuning"

• Section 3.4, "Best Practices"

For more information about tuning the JRockit JVM, see Chapter 4, "Tuning the Memory Management System" and Chapter 5, "Tuning Locks."

3.1 Step 1: Basic Tuning

Basic tuning consists of the following tasks:

• Tuning the Heap Size

• Tuning the Garbage Collection

• Tuning the Nursery Size

• Tuning the Pause Target

3.1.1 Tuning the Heap Size

The heap is where the Java objects are located. While a large heap requires fewer garbage collections, it can take longer to complete these collections. Typically, a heap should be at least twice the size of the live objects in the heap, meaning that at least half of the heap should be freed at each garbage collection. For server applications, you can usually set the heap as large as the available memory in your system allows, as long as this does not cause paging.

Use the following command-line options to set the heap size:

• -Xms:size: To set the initial and minimum heap size

• -Xmx:size: To set the maximum heap size

Example:

java -Xms:800m -Xmx:1000m MyServerApp

This command starts the JVM with a heap of 800 MB and allows the heap to grow up to 1000 MB.

For more information about setting the heap size, see Section 4.1.1, "Setting the Heap Size."

3.1.2 Tuning the Garbage Collection

Garbage collection reclaims space from objects that are no longer in use so that new objects can be allocated to this space. During garbage collection, system resources are used. By tuning the garbage collection, you can decide how and when the resources are used. The JRockit JVM has three garbage collection modes and a number of static garbage collection strategies. These enable you to tune the garbage collection to suit requirements of your application.

Select the garbage collection mode by using one of the following command-line options:

• -Xgc:throughput optimizes garbage collection for application throughput.

• -Xgc:pausetime optimizes garbage collection for short garbage collection pauses.

• -Xgc:deterministic optimizes garbage collection for very short and predetermined garbage collection pauses.

  The -Xgc:deterministic option is available only as part of Oracle JRockit Real Time (for more information about Oracle JRockit Real Time, see Oracle JRockit Real Time Introduction)

You might start a transaction-based application that requires low latencies with the following command:

java -Xgc:pauseTime MyTransactionApp

This command starts the JVM with garbage collection optimized for short garbage collection pauses.

For more information about selecting a garbage collection mode or a static garbage collection strategy, see Section 4.2, "Selecting and Tuning a Garbage Collector."

3.1.3 Tuning the Nursery Size

Some of the garbage collection modes and strategies in the JRockit JVM use a nursery. The nursery is an area of the heap where new objects are allocated. When the nursery becomes full it is garbage collected separately in a young collection. The frequency and duration of young collections is determined by the nursery size. A large nursery decreases the frequency but the duration of each young collection might increase.

The nursery size is adjusted automatically to optimize for application throughput if you use the -Xgc:throughput or -Xgc:genpar option. Typically, the nursery size should be as large as possible while maintaining short young collection pauses. Depending on the application, a nursery size can be anything from a few megabytes up to half of the heap size.

Set the nursery size by using the -Xns:size command-line option.

Example:

java -Xms:800m -Xmx:1000m -Xgc:pausetime -Xns:100m MyTransactionApp

This command starts the JVM with a heap of 800 MB, allowing it to grow up to 1000 MB. The garbage collection is set to optimize for pause times, and the nursery size is set to 100 MB.

For more information about tuning the nursery size, see Section 4.1.2, "Setting the Nursery and Keep Area Size."

3.1.4 Tuning the Pause Target

The -Xgc:pausetime and -Xgc:deterministic command-line options use a pause target for optimizing the pause times while keeping the application throughput as high as possible. A higher pause target usually allows for a higher application throughput; therefore, set the pause target as high as your application can tolerate.

Set the pause target by using the -XpauseTarget:time command-line option.

For example, a transaction-based application with transactions that usually take 100 milliseconds and time out after 400 milliseconds is started with the following settings:

java -Xgc:pausetime -XpauseTarget:250ms MyTransactionApp

The JVM starts with garbage collection optimized for short pauses with a pause target of 250 milliseconds. This leaves a 50 milliseconds margin before time-out for 100 milliseconds transactions that are interrupted by a 250 milliseconds garbage collection pause.

For more information about tuning the pause target, see Section 4.2.1.2.1, "Setting a Pause Target for Pausetime Mode."

3.2 Step 2: Performance Tuning

To tune your JVM for better application throughput, you must first assess the throughput. A common way of measuring the application throughput is to time the execution of a predefined set of test cases. Optimally, the test cases must simulate different use cases and they must be as close to real scenarios as possible. Also, one test run should take at least a few minutes, so that the JVM has time to warm up.

The following sections describe a few optional performance features that could improve the performance for many applications.

• Call Profiling

• Large Pages

3.2.1 Call Profiling

Call profiling enables the use of more advanced profiling for code optimizations and can increase the performance for many applications.

To use this feature on your application, add the following option to the Java command line:

-XX:+UseCallProfiling

For more information about the -XX:(+|-)UseCallProfiling option, see the Oracle JRockit Command-Line Reference.

3.2.2 Large Pages

A large page is essentially a block of contiguous physical-memory addresses that are reserved for a process.

Benefits

Large pages help in improving the performance of applications that require a lot of memory and access memory frequently.

When a process seeks data from memory, the processor looks up the translation look-aside buffer (TLB) — a cache of recently used virtual-to-physical address space translations stored in the processor memory — to find out the physical addresses (RAM or hard disk) that hold the require data. When large pages are enabled, a single entry in the TLB could represent a large contiguous address space, potentially reducing the TLB-lookup frequency and improving performance. In addition, when large pages in physical memory are reserved for a memory-intensive process, the CPU needs to track a small number of pages: for example, only 1024 large (2 MB) pages for a process running with 2 GB of heap, as opposed to 524288 small (4 KB) pages; so it is more likely that the virtual-to-physical address translation for the required data exists in the TLB, without which the processor would need to resort frequently to the slower method of reading the hierarchical page table stored in memory.

Drawback

When a large portion of physical memory is reserved for a process, other applications running on the system might encounter excessive paging (data swapped between hard disk and RAM), affecting the overall performance of the system.

Prerequisite for Using large pages

Support for large pages should be available and enabled in your operating system. The use of large memory pages is enabled by default on Solaris, but needs to be explicitly enabled on Windows and Linux systems.

For information about how to enable large pages on specific operating systems, see http://java.sun.com/javase/technologies/hotspot/largememory.jsp and the documentation for your operating system (Windows: http://technet.microsoft.com/en-us/library/ms190730.aspx; Linux: see the vm/hugetlbpage.txt file in the kernel documentation).

Note:

Even with operating systems in which the support for large pages is available and enabled, at times, the JVM might not be able to reserve large pages because the pages might not be contiguous. To ensure that the JVM can use large pages, you must enable large pages in the operating system as soon as possible after the system starts (possibly, by using a startup script); otherwise, ongoing memory usage can cause fragmentation leading to reduction in the number of available contiguous large pages. Rebooting the system might solve this problem.

Procedure for Enabling Large Pages in the JRockit JVM

When running the JRockit JVM on operating systems in which large pages are supported, you can enable large pages by using the -XX:+UseLargePagesFor[Heap|Code] option. For more information, see the Oracle JRockit Command-Line Reference.

3.3 Step 3: Advanced Tuning

Some applications benefit from further tuning. Verify the results of the tuning by monitoring and benchmarking your application. Advanced tuning of the JRockit JVM, if done correctly, could improve the performance and predictable behavior; incorrect tuning can cause uneven performance, low performance, or performance degradation over time.

This section describes the following topics:

• Tuning Compaction

• Tuning the Thread Local Area Size

3.3.1 Tuning Compaction

Compaction moves objects closer to each other in the heap, reducing the fragmentation and making object allocation easier for the JVM. The JRockit JVM compacts part of the heap at each garbage collection (or old collection, if the garbage collector is generational).

Compaction can cause long garbage collection pauses. To assess the impact compaction has on garbage collection pauses, you can monitor the -Xverbose:compaction or -Xverbose:gcpause outputs or create a recording with the JRockit Flight Recorder and examine the garbage collection pauses in that recording. Look for old collection pause times and pause parts called compaction and reference updates. The compaction pause times depend on the compaction ratio and the maximum references. For more information about JRockit Flight Recorder, see the Oracle JRockit Flight Recorder Run Time Guide.

3.3.1.1 Compaction Ratio

The compaction ratio determines the percent of the heap to be compacted during each old collection.

You can specify the compaction ratio by using the following option:

-XXcompaction:percentage=percentage

If the compaction causes undesirably long garbage collections, tune the compaction ratio. First, lower the compaction ratio to 1.

• If the garbage collection time returns to expected levels, gradually increase the compaction ratio until the garbage collection time becomes too long. A good value for the compaction ratio is usually between 1 and 20.

• If the garbage collection time is long even after you set the compaction ratio to 1, change the maximum references as described in Section 3.3.1.2.

Setting the compaction ratio too low might increase the fragmentation and dark matter (that is, free space too small to be used for object allocation). You can see the amount of dark matter in the JRockit Flight Recorder recordings. For more information, see the Oracle JRockit Flight Recorder Run Time Guide.

3.3.1.2 Maximum References

By setting maximum references, you can define a limit that restricts the number of references that can be made to objects within a compaction area. If the number of references exceeds this limit, the compaction is canceled.

You can define the maximum references by using the following option:

-XXcompaction:maxReferences=value

If the compaction causes undesirably long garbage collections, tune the maximum references. First, set the maximum references as low as 10000. If that solves the problem, gradually increase the maximum references until the compaction times become too long. A typical value for the maximum references is between 100000 and several million. Lower values are used when the pause time limits are very low.

Setting the maximum references too low can stop the compaction altogether. This appears in the verbose logs or in a JRockit Flight Recorder recording as a "skipped" compaction. Running without any compaction at all can lead to increased fragmentation, which, in the end, forces the JVM to perform a full compaction of the entire heap at once. This can take several seconds. Oracle recommends that you do not decrease the maximum references unless absolutely necessary.

Note:

The - XXcompaction:maxReferences option has no effect when the -Xgc:deterministic or -Xgc:pausetime options are used. For these garbage collection modes, do not tune the compaction manually; use the -XpauseTarget option to tune the garbage collection pauses.

For more information, see Section 4.3, "Tuning Compaction."

3.3.2 Tuning the Thread Local Area Size

Increasing the Thread Local Area (TLA) size is beneficial for multi-threaded applications where each thread allocates a lot of objects. Increasing the TLA size is also beneficial when the average size of the allocated objects is large because this allows larger objects to be allocated in the TLAs; however, increasing the TLA size too much can cause more fragmentation and more frequent garbage collections. To assess the sizes of the objects allocated by your application, create a JRockit Flight Recorder recording and view object allocation statistics in the JRockit Flight Recorder. For more information about JRockit Flight Recorder, see Oracle JRockit Flight Recorder Run Time Guide.

The TLA size is set using the following option:

-XXtlaSize:min=size,preferred=size

The min value is the minimum TLA size, while the preferred value is a preferred size. This means that TLAs will be the preferred size whenever possible, but can be as small as the min size. Typically, the preferred TLA size can be up to twice the size of the largest commonly used object in the application. Adjusting the minimum size can affect the garbage collection performance, but it is seldom necessary. A typical value for the minimum size is 2 KB.

For more information about tuning the TLA size, see Section 4.4, "Optimizing Memory Allocation Performance."

see this you will know more http://pindao.huoban.taobao.com/tms/channel/huangguan.htm?pid=mm_24766140_0_0

http://www.tmall.com/go/chn/tbk_channel/tmall_new.php?pid=mm_15321926_0_0&eventid=101334