BEA WebLogic 8.1 SP5 Performance Optimization

Author: S. Johnny

I. Preface
This document is applicable to the oop8 production environment and applies to all servers if not specified.

Based on the Redhat Enterprise Linux 4 Update 1 operating system.

Bold italics indicate commands that can be directly run.

Underline indicates the content of the file.

Ii. Selection of JVM
BEA WebLogic 8.1 SP5 is adopted. According to Bea's official recommendation, the 32-bit Operating System Based on the x86 series is recommended, and Bea jrockit JVM is recommended for optimal execution performance.

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 systems (including garbage collection) and thread systems. In terms of the memory management subsystem, there is a lot of optimization work to do.

Iii. Operating System Optimization
According to Bea's official recommendations, we recommend using the following optimization method based on the Linux operating system's Bea Weblogic.

Parameter
Suggested Value
 
/Sbin/ifconfig lo MTU
1500
 
Kernel. msgmni
1024
 
Kernel. SEM
1000 32000 32 512
 
FS. File-max
65535
 
Kernel. shmmax
2147483648
 
Net. ipv4.tcp _ max_syn_backlog
8192
 

Iv. JVM Optimization Options
1. Set the initial heap size
You can set the initial heap size through-XMS: 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: 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: to set the nursery size. We should increase the nursery size as much as possible while keeping 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 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 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 [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

5. JVM optimization steps
Although jrockit provides a set of default configuration options, it is best to adjust jrockit based on actual application conditions.
1. Determine the optimization methods
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.

6. WebLogic Optimization
The Performance Optimization for WebLogic servers involves the following content.

Element
Attributes
Console Field
For information
 
Server
Nativeioenabled
Native Io Enabled
See using weblogic server "native Io" performance packs.
 
Executequeue
Threadcount
Thread Count
See tuning the default execute queue threads.
 
Executequeue
Queuelength

Queuelengththresholdpercent

Threadsincrease

Threadsmaximum

Thread priority
Queue Length

Queue Length threshold percent

Threads increase

Threads maximum

Thread priority
See tuning execute queues for overflow conditions.
 
Server
Stuckthreadmaxtime

Stuckthreadtimerinterval
Stuck thread Max time

Stuck thread timer Interval
See tuning the execute thread detection behavior.
 
Server
Threadpoolpercentsocketreaders
Socket readers
See allocating execute threads to act as socket readers.
 
Server
Acceptbacklog
Accept backlog
See tuning connection backlog buffering.
 
Jdbcconnectionpool
Initialcapacity

Maxcapacity
Initial Capacity

Max capacity
See how JDBC connection pools enhance performance.
 
Jdbcconnectionpool
Statementcachesize
Statement cache size
See caching prepared and callable statements.
 

 

The core component of Weblogic server is composed of the listening thread, socket multiplexing, And the execution queue of the executable thread. After the server receives a connection request from the listening thread, it gives control over the connection to the socket multiplexing waiting to receive the request. Then, the socket multiplexing reads the request that leaves the socket and places the request and related security information or transaction processing environment together in the appropriate execution Queue (generally the default execution Queue ). When a request appears in the execution queue, an idle execution thread will take the request from the queue and return a response. Then, wait for the next request. Therefore, to improve WebLogic performance, you must adjust the performance of core components.

1. Use the local I/O Library whenever possible
WebLogic Server has two socket multiplexing sets: Java version and local database. It is more effective to use a small local database. Enable Native io (default) should be activated as much as possible. At this time, Unix uses CPUs + 1 thread by default, and double CPU under window. If the system cannot load the local database, a java. Lang. unsatisfiedlinkexception will be thrown. In this case, you can only use Java Socket multiplexing. You can adjust the percentage of socket readers, Which is 33% by default. You can set this parameter in the console server tuning configuration column.

2. Adjust the default number of execution threads
The ideal default number of execution threads is determined by many factors, such as machine CPU performance, bus architecture, I/O, operating system process scheduling, and JVM thread scheduling. By default, WebLogic has 25 threads in the production environment. As the number of CPUs increases, WebLogic can increase the number of threads almost linearly. The larger the number of threads, the more time it takes to switch between threads. The smaller the number of threads, the more insufficient the CPU. To obtain an ideal number of threads, it must be tested repeatedly. During the test, adjustments can be made based on 25 * CPUs. When there are few Idle threads and the CPU utilization is low, you can increase the number of threads (each five threads increases ). For PC server and window 2000, it is recommended that each CPU is smaller than 50 threads, and the CPU utilization is about 90%. Currently, WebLogic execution threads do not have the function to reduce the number of threads. Therefore, set the threads increase parameter to 0 and do not change the priority.

3. Adjust connection Parameters
The Weblogic server uses the accept backlog parameter to specify the size of the queue requested by the server to the operating system. The default value is 50. When the system is overloaded, this value may be too small. Connection refused is reported in the log, causing the valid connection request to be rejected. In this case, the accept backlog 25% can be increased until the connection rejection error disappears. For portal applications, the default value is often insufficient. The login timeout and SSL login timeout parameters indicate the timeout time for normal connections and SSL connections. If the client connection is interrupted by the server or the SSL capacity is large, you can increase the value. These parameters can be found in the console server tuning configration configuration bar.

4. Create a new execution queue
Creating a new execution queue helps solve core business priorities, avoid cross-blocking, deadlock, and long-time processing services. Generally, you can set different priorities for your execution queue and the default execution queue. The priority cannot be set to 9 or 10. It is easy to define a new execution queue. You can use the configure a new excute queue link in the view excute queue option to create a new execution queue. After creating a new execution queue, You need to configure a Allocation Policy for the J2EE component of the application so that it can find the new queue. For example, to bind a servlet or JSP to a specific execution queue, you must replace the web. XML file, set the WL-Dispatch-policy initialization parameter to your own execution queue name.

 

5. JDBC Optimization
The optimization of JDBC connection pool is subject to the setting of WebLogic Server thread count, database process count, and cursor size. We usually use a connection in a thread, so the number of connections is not the more the better. To avoid resource consumption on both sides, we recommend that you set the maximum value of the connection pool to be equal to or slightly smaller than the number of threads. In addition, to reduce the overhead of new connections, set the minimum and maximum values to the same value.
Increasing the statement cache size is helpful for applications that use a large number of preparedstatement objects. WebLogic can cache these objects for each connection. The default value is 10. You can increase the statement cache size as needed to ensure that the database cursor size is sufficient. For example, if you set the number of connections to 25 and the cache size to 10, the database may need to open 25*10 = 250 cursors. Unfortunately, when you encounter an application error related to preparedstatement cache, you need to set the cache size to 0.
Although the JDBC Connection Pool provides many advanced parameters that are useful in the development mode, most of them do not need to be adjusted in the production environment. We recommend that you do not set a test table, and test reserved connections and test released connections do not need to be checked. Of course, if your database is unstable, you may need to open the above parameters.
Finally, let's take oracle as an example. Oracle provides the thin driver and OCI driver. In terms of performance, the OCI driver is better than the thin driver, especially for large data volume operations. However, in simple database operations, the performance does not differ much. With the continuous improvement of the thin driver, this weakness will be compensated. Thin drivers are more portable than OCI drivers. Therefore, we recommend that you use the thin driver. The latest drive may not be the latest class package in the WebLogic Server/bin directory, so it can be downloaded from the official Oracle website.

VII. jrockit 1.4.2 parameter list
Option name
Description
Used in
 
-Classpath
-CP
Tells Bea jrockit JVM where to look for classes and resources.
Configuration
 
-Client
Starts Bea jrockit JVM in the client mode. This option is useful when you are using a small heap and are anticipating relatively short runtimes.

You shoshould be aware that setting the JVM type (or accepting the default) will also set the garbage collection algorithm that will be used during runtime. -Client will start a single-spaced, concurrent mark, concurrent sweep garbage collector (see using the BEA jrockit Memory Management System for more information ).
Configuration
 
-D
Tells Bea jrockit JVM to set a Java System property. These can be read by a Java program, using the methods in Java. Lang. system.
Configuration
 
-Help
Tells Bea jrockit JVM to display a short help message.
Configuration
 
-Jrockit
Starts jrockit in server mode. This option does the same as starting the JVM with the option-server.
 
 
-Server
Starts Bea jrockit JVM as a server-side JVM. This value is the default.

You shoshould be aware that setting the JVM type (or accepting the default) will also set the garbage collection algorithm that will be used during runtime. -server will start a single-spaced, parallel mark, parallel sweep collector (see using the BEA jrockit Memory Management System for more information ).
Configuration
 
-Showversion
Tells Bea jrockit JVM to display its product version number and then continue with startup.
Configuration
 
-Verbose
-Xverbose
Tells Bea jrockit JVM to display verbose output.
Configuration
 
-Version
Tells Bea jrockit JVM to display its product version number and then exit.
Configuration
 
-X
Tells Bea jrockit JVM to display a short help message on the extended options.
Configuration
 
-Xbootclasspath
Sets the search path for bootstrap classes and resources for Bea jrockit to use instead of those supplied with the j2se SDK. specify the names of the directories ,. zip, and. jar files, separated by ";" (Windows) or ":" (Linux ).
Configuration
 
-Xbootclasspath/
Sets the search path for bootstrap classes and resources for Bea jrockit to use instead of those supplied with the j2se SDK and appends the information to the default Bootstrap class path.

Example:
-Xbootclasspath/A:/path/to/classes
Configuration
 
-Xbootclasspath/P
Sets the search path for bootstrap classes and resources for Bea jrockit to use instead of those supplied with the j2se SDK and prepends the information to the default Bootstrap class path.

Example:
-Xbootclasspath/P:/path/to/classes
Configuration
 
-Xcleartype
Defines when the memory space occupied by an object that has been garbage collected will be cleared. The parameters listed below determine when the space is cleared.

Parameters:

GC; cleared during garbage collection
Local; cleared when a thread-local area is allocated
Alloc; cleared when that space is allocated for a new object

Notes:
The alloc option is not available on IA64 systems.

Default:
If the clear type is not set, the default is alloc on ia32 systems and GC on IA64 systems.
Memory Management
 
-Xgc
Deploys the specified fixed garbage collector.

Parameters:

Singlecon; single spaced concurrent
GENCON; generational concurrent
Parallel; parallel

Default:
The default is parallel when running with the-server option specified (default behavior) and singlecon when running with the-client option specified. (see information about client and server mode specified above)
Memory Management
 
-Xgcpause
Prints pause times caused by the garbage collector.
Memory Management
 
-Xgcprio
Sets the unified Garbage Collector according to the specified priority:

Throughput: the time between when an object is no longer referenced and the time that it's reclaimed and returned as free memory. the higher the memory throughput The shorter is the time between the two events.
Pausetime: the length of time that the Garbage Collector stops all Java threads during a garbage collection. The longer the pause, the more unresponsive your system will be.
Note:
-Xgcprio is a non-supported option for jrockit 1.4.2.
Memory Management
 
-Xgcreport
Causes Bea jrockit JVM to print a comprehensive garbage collection report at program completion. The option-xgcpause causes the VM to print a line each time Java threads are stopped for garbage collection.
Memory Management
 
-Xjvmpi
Enables and disables groups of jvmpi events when running jvmpi. The events are:

Entryexit (default is on)
Allocs (default on)
Monitors (default (on)
Arenasdelete (default off)

Note:
Jvmpi is an experimental feature in the Java 2 SDK and is not yet a standard profiling interface.
Configuration
 
-Xmanagement
Enables the management server in the VM, which needs to be started before the management console can connect to jrockit JVM.

By using the class = and classpath = parameters with-xmanagement (-xmanagement: class =, classpath =) You can specify a management class and its classpath. this option loads the class and causes its empty constructor to be called early in JVM startup. from the constructor, a new thread is then started, from which your management client is run.
Bea jrockit Management Console
 
-XMS
Sets the initial size of the heap. you shoshould set the initial heap size (-XMS) to the same size as the maximum heap size. this value can be specified in kilobytes (K, k), megabytes (M, m), or gigabytes (G, G ).

Default:
The default value depends upon the JVM mode:

-Server mode: The default value is the lesser of 75% of physical memory or 1536 MB.
-Client mode: The default value is the lesser of 75% of physical memory or 64 MB.
Tuning
 
-Xmx
Sets the maximum size of the heap. Use the following guidelines to determine this value:

On ia32 the maximum possible heap size is about 1.8 GB (which is the largest contiguous address space the o/s will give a process ). for Windows 2000 the largest possible heap is 1.6 GB and for Windows 2003 it is 1.8 GB.
The 1.8 GB limit does not apply to IA64 machines, because they have a larger address space.
Typically, for any platform you don't want to use a larger maximum heap size setting than 75% of the available physical memory. this is because you need to leave some memory space available for internal usage in the JVM.
On ia32 machines running Windows 2000, you can use the 3 GB mode to increase the memory available to the process. for more information, please refer to the/gb3 parameter documentation, available from the Microsoft developers network.
This value can be specified in kilobytes (K, k), megabytes (M, m), or gigabytes (G, G ).

Note:
If you encounter outofmemory errors, you shocould increase the maximum heap size according to the preceding guidelines.

Default:
The default value is the lesser of 75% of physical memory or 1536 MB.
Tuning
 
-Xnativethreads
Enables the native threads system.
Configuration
 
-Xnoclassgc
Disables class garbage collection.
Memory Management
 
-Xnoopt
Tells Bea jrockit JVM not to optimize code.
Configuration
 
-Xns
Sets the size of the nursery in generational concurrent garbage collectors. optimally, you shocould try to make the nursery as large as possible while still keeping the garbage collection-pause times acceptably low. this is particle ly important if you are creating a lot of temporary objects.

Notes:
To display pause times, include the option-xgcpause when you start Bea jrockit 1.4.2 JVM.

Bea jrockit 1.4.2 JVM has no specific rule regarding the maximum size of a nursery, however it shoshould never exceed the maximum heap size.

Default
The default value depends upon the JVM mode:

-Server mode: the default nursery size is 10 MB per CPU; for example, the default for a ten CPU system wocould be 100 MB.
-Client mode: the default nursery size is 2 MB.
Tuning
 
-XSS
Sets the thread stack size. This value can be specified in kilobytes (K, k), megabytes (M, m), or gigabytes (G, G ).

Note:
The minimum thread stack size is 16 kilobytes. If-XSS is set below the minimum value, thread stack size will default to the minimum value automatically.
Tuning
 
-Xverbose
Causes Bea jrockit to print to the screen, upon startup, specific information about the system. The information displayed depends upon the parameter specified with the one of these options:

Codegen
Cpuinfo
GC
Load
Memory
OPT
For a description of these options, please refer to table 3-1 in starting and inserting ing Bea jrockit.
Configuration
 
-Xverbosetimestamp
Force a timestamp to print out with other information generated by-xverbose by using the command-xverbosetimestamp. When you use this command, the time and date will precede the verbose information.
Configuration
 
-Xverify
Tells Bea jrockit JVM to do complete bytecode verification.
Configuration