BEA WebLogic jrockit usage and Performance Tuning

BEA WebLogic jrockit usage and Performance Tuning

1. Introduction to jrockit Optimization
Jrockit is an adaptive JVM that can automatically adjust itself to adapt to the underlying hardware. Therefore, its optimization is mainly focused on parameters that require manual intervention, such: the number of Ram resources to be allocated to jrockit. Jrockit has a set of non-standard-x startup options that we can use to adjust JVM. Jrockit has two major groups of subsystems that can be optimized: Memory Management System (including garbage collection) and thread system. In terms of the memory management subsystem, there is a lot of optimization work to do.

Ii. tuning WebLogic jrockit JVM
1. Set the initial heap size
You can set the initial heap size through-XMS: <size> M. If the value of-xmx is smaller than 128 MB, the default value of-XMS is 16 Mb; if the value of-xmx is greater than 128 MB, the default value of-XMS is 25% of the physical memory, and the maximum value is 64 MB. Example:

-Xgc: GENCON-XMS: 64 m-xmx: 64 m myclass
2. Set the maximum heap size.
You can use-xmx: <size> m to set the maximum heap size. In the ia32 architecture, the maximum size of the heap cannot exceed 1.8 GB because the maximum memory addressing space provided by the operating system to each process is 1.8 GB. In the IA64 architecture, there is no 1.8g restriction.

If your Java application encounters an out of memory error during runtime, you need to increase the maximum heap size. If the maximum heap size is not set, the default value is:
1. If-xgc: gencopy is set, the maximum heap size is min {400, and the physical memory is * 75% };
2. If-xgc: gencopy is not set, the maximum heap size is min {1536, and the physical memory is * 75% };
It is best to manually set the maximum heap size to 1024 of the physical memory (75% MB:
-Xgc: GENCON-XMS: 64 m-xmx: 768 m myclass
3. Set the nursery size
You can use-xns: <size> to set the nursery size. We should increase the nursery size while keeping the garbage collection-pause as short as possible, this is especially important when a large number of temporary objects are created. The default value is:

1. For-xgc: gencopy, the default nursery size is 320kb/CPU. For 10 CPU Systems, the size of nursery is 3200kb (3.2 m)
2. For-xgc: GENCON, the default nursery size is 10 m/CPU. For systems with 10 CPUs, the nursery size is 100 m
4. Define the memory space clearing time

You can use-xcleartype: <GC | Local | alloc> to define when the garbage collection memory space can be cleared. The following three methods are supported:

1. GC: clean up the memory while garbage collection;
2. Local: the memory is cleared when a thread-local area is allocated. It is only useful when the parameter-xallocationtype is set to local;
3. alloc, Which is cleared when the memory is allocated to other objects. It is not currently supported on IA64.
The default value is:
1. The default value on ia32 is alloc.
2. The default value on IA64 is GC.
5. Define the thread allocation type
You can use-xallocationtype: <global | Local> to define the type of thread allocation.
1. Global, used when the maximum heap size is relatively small (less than 128 M) or applications use a large number of threads.
2. Local, used when the maximum heap size is large (greater than 128 M) or the application uses a small number of threads.
Default Value:
1. If-xgc: gencopy is set, the default value is global.
2. If-xgc: siglecon,-xgc: GENCON and-xgc: parallel are set, the default value is local.
6. Define the thread stack size
You can use-XSS <size> [k | K] [M | M] to define the thread stack size. The minimum thread size is defined as follows:
1. thin threads: The minimum thread stack size is 8 K. The default value is 64 K;
2. Native threads: The minimum thread stack size is 16 kb.
If-XSS is set to be smaller than the minimum value, the minimum value is automatically used.
Default Value:
1. ia32 system, Win32: 64 K, linux32: 128 K
2. IA64 system, win64: 320 k, linux64: 1 m

Ii. Basic tuning tips and Techniques
Although jrockit provides a set of default OOTB configuration options, it is best to make some adjustments to jrockit based on actual application conditions.
1. determine where you want to optimize
The following factors should be taken into account:
1. How much memory is allocated for jrockit;

2. What is the purpose of optimization? Is it better responsiveness or performance;
2. Set heap size
The larger the heap size, the better. If the memory size is not large enough, the out-of-memory and memory paging errors will occur. If multiple applications are running at the same time, we recommend that you set the minimum and maximum heap sizes to the same size.

3. High responsiveness Tuning
For better response performance, Set
1. Use the concurrent garbage collector. -Xgc: GENCON
2. Set the initial and maximum heap size. -Xms512m,-xmx768m. Because the concurrent garbage collector is used, the heap size does not cause a long wait.
3. Set the nursery size. If a large number of temporary objects are used, you need to increase the nursery size appropriately. Increasing the nursery size leads to longer pause time for garbage collection. Therefore, make sure that the pause time for garbage collection is within the tolerable range. You can set this pause time by setting-xgcpause.

4. High Performance Tuning
To achieve better performance, you should:
1. Select the parallel garbage collector. Because the parallel garbage collector does not use nursery, you do not need to set-xns. The method is to add-xgc: parallel.
2. Set the initial and maximum heap size to the maximum possible size. The method is-xms512m and-xmx768m.
5. Analyze garbage collection and pause time
1. Use-xgcreport to generate a report and display the garbage collection statistics. You can see if you have used the Garbage Collector most effectively.
2. Use-xverbose: memory to display the pause time for each garbage collection during running. This option is only used for debugging and produces a large amount of console output.
6. Adjust thread options
When a large number of threads are used (more than 100), you need to adjust the thread options:
1. Use the thin thread option. -Xthinthreads. The thin thread mode is very effective in Linux. Note: The thin thread is only a test option in jrockit and is not recommended to be widely used;
2. Disable the local thread allocation option. -Xallocationtype: Global. Each local thread area consumes about 2 K of memory. If a large number of threads are used, the local thread will not only cause a waste of memory space, but also cause heap fragmentation. Using the global thread mechanism will reduce heap fragmentation, but it will be slower in terms of memory allocation.

7. analyze and improve application design
Identify the bottleneck:
1. Use the Intel vtune tool;
2. Use the-xjvmpi: allocs = OFF, monitors = OFF, entryexit = off option.

Iii. command line options by name
When jrockit is started, some-x options can be included. These options are non-JVM standard and are used to configure jrockit performance.
Option description
-X
Show extended Java options

-Xallotype

-Xallocationtype
Optional values: global and local. You can define whether to use a local thread or a global thread.

-Xbootclasspath
Specifies the Class search path, which can be zip and jar files separated by; or:

-Xcleartype
Specifies the memory cleaning time. values include GC, local, and alloc. GC indicates memory cleanup during garbage collection; Local indicates cleanup when a local thread area is allocated; alloc indicates cleanup when the memory area is allocated to other objects.

-Xgc
Select the type of the garbage collector to use. Valid value:

Gencopy: generational copying

Singlecon: single spaced concurrent, single-space concurrency

GENCON: generational concurrent

Parallel: Parallel

If-xmx is less than 128 M, gencopy is used by default; otherwise, GENCON is used.

-Xgcpause
Print the pause time caused by the Garbage Collector

-Xgcreport
Print the garbage collection report

-Xjvmpi
Whether jvmpi events are allowed. These events include:

Entryexit (on by default)

Allocs (default on)

Monitors (default on)

Arenasdelete (default off)

-Xmanagement
To activate the Management Server in JVM, you must activate it before you can connect to the management server in the JVM console.

-XMS
Set the initial heap size in the unit of K, M, and G.

-Xmx
Sets the maximum heap size. The unit is K, M, and G.

-Xnativethreads
Use the local thread system. This is the default option.

-Xnoclassgc
Garbage collection is prohibited.

-Xnohup
Tell jrockit to ignore ctrl_logoff_event and sighup events

-Xns
Set the nursery size in the unit of K, M, and G.

-XSS
Set the thread stack size in the unit of K, M, and G.

-Xthinthreads
Jrockit's high-performance thread system is not available on IA64.

-Xverbose
Let jrockit print more information. The optional parameters include:

Codegen, cpuinfo, GC, load, memory, OPT

-Xverify
Complete bytecode-level verification

4. Use method profiler in jrockit8.1 to tune WebLogic
1. About the method profiler Tool
BEA WebLogic jrockit 8.1 provides a profiling tool: Method profiler to optimize WebLogic applications.
2. Use method profiler to optimize WebLogic applications
The method profiler tool in jrockit 8.1 can calculate the number of calls, total execution time, and execution time of each member method executed on jrockit Java virtual machine, as shown in 1. This feature allows us to perform tuning (Code-level) on the applications running on WebLogic, and also makes it easier for us to determine where the system bottleneck is. This is also a major advantage of jrockit JVM over other JVM functions.


In a stress test on WebLogic Server 8.1, when a group of samples containing CMP characteristics are tested, jrockit's method profiler is used to diagnose the bottleneck of the system, the following is an introduction. In this CMP group, the operations on the CMP Entity Bean in addition to inserting a record with ejbcreate are followed by setting the name attribute using the setname method, that is, updating the value of the Name field in the corresponding database record, the Code is as follows:

Public void ejbcreate () // method in stateful4cmpbean
Throws createexception
{
Try
{
Context CTX = new initialcontext ();
Sheephome home = (sheephome) CTX. Lookup ("Sheep ");
Sheep sheep = NULL;
Int x = getnextid (); // getnextid () also contains database operations
Sheep = home. Create (X );
If (sheep! = NULL)
{
Sheep. setname ("sheep1". Concat (string. valueof (string. valueof (X ))));
M_strmsg = "create sheep". Concat (string. valueof (string. valueof (X )));
} Else
{
M_strmsg = "the sheep name is not created .";
}
}
Catch (exception E)
{
M_strmsg =
"*** Some exception occured! (CMP) ". Concat (string. valueof (string. valueof (E. getmessage ())));

}
}
At this time, the TPS average value of the tested data is very low, and the response time always increases linearly with the increase of time. Therefore, use method profiler for diagnosis:
(1) Add-xmanagement to the jrockit startup parameters to enable the Management Server when jrockit is started.
(2) Start the jrockit management console and connect it to the started management server. (When performing stress tests, use the jrockit Management Console to observe and ignore the performance loss)

(3) In the jrockit Management Console, set the mode of operation attribute in the tools à preferences menu to developer.

(4) Add the member methods of the class you need to observe on the method profiler property page.
(5) press start to start method profiler.
The display result of the time/INV (NS) indicator shows that the logic contained in the stateful4cmpbean. ejbcreate () code has become the bottleneck of the system. The results show getnextid () and home. the create () operation consumes only stateful4cmpbean time. A small part of ejbcreate (), while sheep. the time consumed by the setname () operation occupies stateful4cmpbean. the rest of ejbcreate () (excluding getnextid () and home. the create () operation consumes most of the time.

Therefore, method profiler was used for a series of experiments. The results are as follows: one user was used for stress testing and sheep. the time consumed by the setname () operation is X, and the time consumed by the getnextid () operation is Y, home. the time consumed by the CREATE () operation is Z. Two users are used for stress testing and sheep. the time consumed by the setname () operation is about 2X, and the time consumed by the getnextid () operation is about y, home. the time consumed by the CREATE () operation is about Z. Three users are used for stress testing and sheep. the time consumed by the setname () operation is about 3x, and the time consumed by the getnextid () operation is about y, home. the time consumed by the CREATE () operation is about Z. It can be judged with certainty that sheep. setname () executes a serialized logic. Check the isolation-level of update in oralce, Which is serializable.

Delete sheep. setname ("sheep1". Concat (string. valueof (string. valueof (X.
The TPS average value has been greatly improved during the retest, and the response time tends to be stable after the stress test starts for a period of time, almost showing a horizontal trend.