Shulou(Shulou.com)06/02 Report--

This article mainly introduces how to use BEA WebLogic JRockit and performance tuning, the article is very detailed, has a certain reference value, interested friends must read it!

I. introduction to JRockit tuning

JRockit is an adaptive JVM, which can automatically adjust itself to the underlying hardware, so its tuning is mainly focused on some parameters that require human intervention, such as how much RAM needs to be allocated to JRockit and so on. JRockit has a set of non-standard-X startup options that we can use to tune JVM. JRockit has two main subsystems that can be optimized-the memory management system (including garbage collection) and the threading system. In terms of the memory management subsystem, there is a lot of tuning that can be done.

II. Tuning WebLogic JRockit JVM

1. Set the initial heap size

You can use-Xms:

M to set the initial heap size. If the value of-Xmx is less than 128MB, the default value of-Xms is 16MB; if the setting of-Xmx is greater than 128MB, the default value of-Xms is 25% of physical memory, and the maximum is not more than 64m. Example:

-Xgc:gencon-xms:64m-Xmx:64m myClass

2. Set the maximum heap size

You can set the maximum heap size with-Xmx:m. Under the IA32 architecture, because the maximum memory address space given by the operating system to each process is 1.8G, the maximum heap size cannot exceed 1.8g. Under the IA64 framework, there is no 1.8G limit.

If your JAVA application runs with an Out of memory error, 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, physical memory * 75%}

2. If-Xgc:gencopy is not set, the maximum heap size is min {1536, physical memory * 75}

It is best to manually set the maximum heap size to 75% of physical memory (1024m):

-Xgc:gencon-xms:64m-Xmx:768m myClass

3. Set the size of Nursery

You can use-Xns: to set the size of Nursery, and we need to increase the size of Nursery as much as possible while keeping the garbage collection pause time (garbage collection-pause) as short as possible, which is especially important when creating a large number of temporary objects. The default value is:

1. For-Xgc:gencopy, the default Nursery size is 320KB/CPU, and for systems with 10 CPU, the Nursery size is 3200KB (3.2m)

2. For-Xgc:gencon, the default Nursery size is 10M/CPU, and for systems with 10 CPU, the Nursery size is 100m

4. Define the timing of memory space cleanup

You can use-Xcleartype: to define when the memory space that has been garbage collected can be cleaned. The following three ways are supported:

1. Gc, cleaning memory while garbage collection

2. Local, which cleans up memory when a thread-local area is allocated, useful only when the parameter-Xallocationtype is set to local

3. Alloc, which cleans up when this 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 type of thread allocation

You can use-Xallocationtype: to define the type of thread allocation.

1. Global, used when the maximum heap size is relatively small (less than 128m) or when the application uses a lot of threads.

2. Local, used when the maximum heap size is large (greater than 128m) or when the application uses a small amount 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 thread stack size

You can use-XSS [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 8K, and the default is 64K

2. Native threads: the minimum thread stack size is 16K

If the-Xss setting is less than the minimum value, the minimum value is automatically used.

Default value:

1. IA32 system, WIN32:64K,LINUX32:128K

2. IA64 system, WIN64:320K,LINUX64:1M

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 the actual application.

1. Decide where you want to tune.

The factors to be considered are:

1. How much memory space to allocate for JRockit

2. What is the purpose of your tuning? do you want better responsiveness or better performance?

2. Set heap size

For heap size, of course, the bigger the better. If the setting is not large enough, it will cause Out-of-memory and memory paging errors. If multiple applications are running at the same time, it is recommended that you set the minimum and maximum heap sizes to the same size.

3. Tuning in terms of high responsiveness

For better response performance, you should set the

1. Use the concurrent garbage collector. -Xgc:gencon

2. Set the initial and maximum heap size. -Xms512m,-Xmx768m, due to the use of the concurrent garbage collector, 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 resize the nursery appropriately. Scaling up the nursery size will result in longer pauses for garbage collection, so be careful to make sure that the pauses for garbage collection are within tolerable limits, which can be seen by setting-Xgcpause.

4. Tuning in high performance

For better performance, you should:

1. Choose the parallel garbage collector. Since the parallel garbage collector does not use nursery, you no longer need to set-Xns by adding-Xgc:parallel.

2. Adjust the initial and maximum heap size settings to as large as possible. The method is-Xms512m,-Xmx768m.

5. Analyze garbage collection and pause time

1. Use-Xgcreport to generate a report showing garbage collection statistics, from which you can see whether you are using the garbage collector most effectively.

2. Use-Xverbose:memory to show the pause time for each garbage collection during operation. This option is for debugging only and produces a large amount of console output.

6. Adjust thread options

When threads are heavily used (more than 100), you need to adjust the thread options:

1. Use the thinthreading option. -Xthinthreads. Thin thread mode is very effective under LINUX. Note: thin threads are only an experimental option in JRockit and are not recommended for wide use.

2. Turn off the option to allocate threads locally. -Xallocationtype:global. Each local thread area consumes about 2K of memory. If a large number of threads are used, local threads will not only waste memory space, but also cause heap fragmentation. Using the global threading mechanism reduces heap fragmentation, but is slower in terms of memory allocation.

7. Analyze and improve application design

The way to identify bottlenecks:

1. Use the Intel VTune tool

2. Use the-Xjvmpi:allocs=off,monitors=off,entryexit=off option.

III. Command Line Options by Name

When you start JRockit, you can bring some-X options that are non-JVM standard and are designed specifically to configure the performance of JRockit.

Option description

-X

Show extended Java options

-Xallotype

-Xallocationtype

Available values global and local define whether to use a local thread or a global thread.

-Xbootclasspath

Specify the class search path, which can be ZIP and JAR files, delimited by; or

-Xcleartype

Define the timing of memory cleanup. Available values include gc, local, and alloc. Gc means to clean up memory during garbage collection; local means to clean up when a local thread area is allocated; alloc means to clean up when the memory area is to be allocated to other objects

-Xgc

Select the type of garbage collector to use. Available values:

Gencopy:generational copying

Singlecon:single spaced concurrent, single space concurrency

Gencon:generational concurrent

Parallel:parallel

If-Xmx is less than 128m, gencopy is used by default, otherwise gencon is used

-Xgcpause

Print the pause time caused by the garbage collector

-Xgcreport

Print garbage collection report

-Xjvmpi

Whether JVMPI events are allowed, these events are:

Entryexit (default ON)

Allocs (default ON)

Monitors (default ON)

Arenasdelete (default OFF)

-Xmanagement

Activate the management server in JVM, which must be activated before the administrative console of JVM can connect to it.

-Xms

Set the initial heap size in K, M, G

-Xmx

Sets the maximum heap size in K, M, G

-Xnativethreads

Use the local threading system, which is the default option

-Xnoclassgc

Garbage collection of classes is prohibited

-Xnohup

Tell JRockit to ignore the CTRL_LOGOFF_EVENT and SIGHUP events

-Xns

Set nursery size in K, M, G

-Xss

Sets the thread stack size in K, M, G

-Xthinthreads

High-performance threading systems that use JRockit are not available on IA64.

-Xverbose

To have JRockit print more information, the optional parameters are:

Codegen 、 cpuinfo 、 gc 、 load 、 memory 、 Opt

-Xverify

Make a complete bytecode level check

IV. Tuning WebLogic with Method Profiler in JRockit8.1

1. About the Method Profiler tool

BEA WebLogic JRockit 8.1 provides a Profiling tool: Method Profiler to tune WebLogic applications.

2. Using Method Profiler to tune WebLogic application

The Method Profiler tool in JRockit 8.1 can count the number of calls to member methods, the total execution time and the execution time of each call executed on the JRockit Java virtual machine. On the one hand, this feature allows us to tuning applications running on WebLogic (code level), and on the other hand, it also greatly facilitates us to determine where the bottleneck of the system is. This can also be said to be a major functional advantage of JRockit JVM over other JVM.

Screen.width-333) this.width=screen.width-333; ">

In a stress test of WebLogic Server 8.1, when a group of samples containing CMP characteristics were tested, the Method Profiler of JRockit was used to diagnose the bottleneck of the system, which is introduced below. In addition to inserting a record with ejbCreate, the original operation on CMP Entity Bean in this group of samples uses the setName method to set its name property, that is, the value of the name field in the corresponding database record of UPDATE. The code is as follows:

Methods in public void ejbCreate () / / Stateful4CMPBean

Throws CreateException

{

Try

{

Context ctx = new InitialContext ()

SheepHome home = (SheepHome) ctx.lookup ("Sheep")

Sheep sheep = null

Int x = getNextId (); / / getNextId () also contains operations on the database

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 average value of TPS is very low, and the Response Time always rises linearly with the increase of time. So use Method Profiler to diagnose:

(1) add-Xmanagement to the startup parameters of JRockit, so that when starting JRockit, start its Management Server at the same time.

(2) start JRockit Management Console and connect it to the started Management Server. (the performance loss caused by JRockit Management Console observation during stress testing is negligible.)

(3) in JRockit Management Console, set the Mode of operation property in the Tools à Preferences menu to developer.

(4) add the member methods of the class you need to observe in the Method Profiler property page.

(5) Press the Start button to let Method Profiler start counting.

The display result of Time/Inv (ns) index shows that the logic contained in Stateful4CMPBean.ejbCreate () code has become the bottleneck of the system. The results also show that the time consumed by getNextId () and home.create () operations is only a small part of that of Stateful4CMPBean.ejbCreate (), while the time consumed by sheep.setName () operations accounts for most of the rest of Stateful4CMPBean.ejbCreate () (excluding the time consumed by getNextId () and home.create () operations).

So a series of experiments are done with Method Profiler, and the results are as follows: using one user to do the stress test, the time consumed by the sheep.setName () operation is the time consumed by the XMagi getNextId () operation is Z; with 2 users doing the stress test, the time consumed by the sheep.setName () operation is about 2XMagnetNextId () operation, which is about the time consumed by the YMagne _ NextId () operation is about Z Using three users for stress testing, the time consumed by the sheep.setName () operation is about 3X _ get _ NextId (), and the time consumed by the YMagne _ home. Create () operation is about Z. It can be judged with relative certainty that sheep.setName () performs a serialized logic. Check the ISOLATION-LEVEL of UPDATE in Oralce, and it is sure enough to be SERIALIZABLE.

Delete the sheep.setName ("sheep1" .concat (String.valueOf (String.valueOf (x); code.

After re-testing, the average value of TPS increased greatly, and Response Time also tended to stabilize after the stress test began for a period of time, almost showing a horizontal trend. These are all the contents of the article "how to use and optimize performance in BEA WebLogic JRockit". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.