Java Performance Optimization-ibm jdk jvm parameter settings

The key to WebSphere Optimization-varies with JDK. This document describes how to set common parameters in ibm jdk.

-XMS: Minimum heap size

-Xmx: Maximum heap size

-Xminf and-xmaxf: Minimum value of available space after GC (garbage collection)

-Xmine and-xmaxe: Minimum heap Growth Value

-Xmint and-xmaxt: Percentage of garbage collection time in the whole running time. The default value is 5%. If the collection time is less than 5%, it will reduce the heap, and vice versa.

In general, as long as the XMS and xmx settings are reasonable, the next three pairs do not need special settings. You can check {
Function onclick ()
{
Function onclick ()
{
Pagetracker. _ trackpageview ('/outbound/article/publib.boulder.ibm.com ');
}
}
} "Href =" http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/index.jsp "> http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/index.jspon heap expasion and heap shrinkage, unless it is described below:

If you use a heap with a variable size (for example,-XMS and-xmx are different), the application may encounter such a situation, and the heap is not extended due to continuous allocation failure. This is the heap failure because the heap size has just been able to avoid expansion but is not enough to solve the allocation failure in the future. In general, the space released in the garbage collection cycle can not only meet the current allocation failure, but also provide a lot of space for future allocation requests. However, if the heap is in an invalid state, the space released in each garbage collection cycle can just meet the current allocation failure. As a result, the next allocation request will go into the garbage collection cycle, and so on. A large number of objects with short survival time may also cause this phenomenon. One way to avoid this loop is to add-xminf and-xmaxf values. For example, if-xminf.5 is used, the heap will increase to at least 50% free space. Similarly, it is reasonable to add-xmaxf. If-xminf is equal to 0.5,-xmaxf is the default value of 0.6, because the JVM needs to keep the free space ratio between 50% and 60%, so there will be too many extensions and condentions. A 0.3 difference between the two is a good choice, so that-xmaxf.8 can match-xminf.5 well. If the record indicates that you need to expand multiple times to reach a stable heap size, but you can change-xmine to set the minimum extension size based on application behavior. The goal is to obtain sufficient available space not only to meet the current request, but also to meet many future requests, thus avoiding excessive garbage collection cycles. -Xmine,-xmaxf, and-xminf provide great flexibility for controlling the memory usage characteristics of applications.

From Java performance optimization policies and common methods

Therefore, it is best to open the GC log for the first time when the application is officially launched, and observe the growth (expasion) and contraction (shrinkage) of heap ). The best case is that the available heap size accounts for about 50% of the total heap size after each recycle. If less than 30% of the available space is reclaimed, adjust the preceding parameters. You can use the-verbose: size parameter to view the current default value.

So why don't we set XMS and xmx as big as sun's JDK recommends?

Using the same values is not usually a good idea, because it delays the start of garbage collection until the heap is full. the first time that the Garbage Collector runs, therefore, becomes a very expensive operation. also, the heap is more likely to be fragmented and require a heap compaction. again this is a very expensive operation. ......

 

If the Garbage Collector cannot find enough garbage, it runs compaction. If the garbage collector finds enough garbage, or any of the other conditions for heap expansion are met, the garbage collector expands the heap.

Because ibm jdk uses mark-scan-mark -...... -Scan-compact. If you do not have enough space, you can extend the expasion ). Cycles until the maximum heap size is reached. Before each extension, the persistent objects are adjusted to the bottom of the heap. After each extension, there is very little need to be moved. Therefore, if XMS is set to be the same as xmx, the overhead of a large heap with memory fragments in scanning and compact arrangement will be much higher than the overhead of a small extended heap.

The overheads of expanding the heap are almost trivial compared to the cost of collecting and compacting a very large fragmented heap.

This is due to the GC characteristics of IBM, and Sun's JDK adopts the generational recycle policy. Therefore, this situation does not occur, but will benefit from consistent heap size. However, if-xgcpolicy: GENCON is used, you should set the maximum heap size as the same.

Under the GENCON recycling policy, you can use-xmn to set the size of the baby area (nursery or young) and-xmo to set the size of the tenured or old area. Note that-xmn cannot be used with the-xmns/-xMnx parameter, and-xmo cannot be used with-Xmos/-xmox. Otherwise, an error is returned. The former is to fix the size of the young generation and the permanent generation, and the latter is to set the maximum and minimum range of the two parts. By default:

-Xmns is-25% or 64 m of XMS (5.0 by default in JDK 25%)

-XMnx is-25% or 64 m of xmx (same as above)

-Xmos:-xmx minus-xmns

-Xmox is as big as-xmx

It can be seen that the default young generation is too small, and it is necessary to change the size in the production environment.Because the young generation uses a replication policy, the recovery speed is quite fast (minor GC), while the permanent generation uses a method similar to the optavgpause policy for concurrent flag and scanning, the collection speed is relatively slow (Major GC ). Ideally, the ratio of minor GC to major GC is around. (You can view the collected regions through GC logs)

The tenure age and tilt ratio parameters of GENCON are dynamically adjusted by JVM.

ForFixed Object Problems (pinned objects), Use the-XK-XP parameter to set kcluster and pcluster ,{
Function onclick ()
{
Function onclick ()
{
Pagetracker. _ trackpageview ('/outbound/article/www-01.ibm.com ');
}
}
} "Href =" http://www-01.ibm.com/support/docview.wss? Uid = swg21176363 "> avoiding Java heap fragmentation with Java SDK v1.4.2.

Some uncommon parameters:

-Xloainitial <percentage>-xloamaximum <percentage>: adjust the size of the large object area. Allocation is always first allocated in SOA (small object area). If there is no space and the size to be allocated is greater than 64 K, it is allocated to Loa. The default value is-xloainitial0.05 (5%) and-xloamaximum0.5 (50%). If your program needs to allocate many large objects (greater than 64 K ), you can adjust the initial percentage of Loa.

For more details about the above two points, refer to the Java heap space fragmentation issue of my ibm jdk.

To sum up, for optthruput and optavgpause, set the appropriate maximum heap and minimum heap, and set-XK and-XP to avoid fragmentation issues. If the program needs to allocate more large objects, then adjust the loa size. For GENCON, you can increase the size of the minimum heap and the maximum heap, and adjust the size of the young region. Loa can also be adjusted as needed. Subpool is generally not used, so we will not study it.

Some additional information

Default settings for the JVM

{
Function onclick ()
{
Function onclick ()
{
Pagetracker. _ trackpageview ('/outbound/article/publib.boulder.ibm.com ');
}
}
} "Href =" http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/index.jsp? Topic =/com.ibm.java.doc. diagnostics.50/diag/appendixes/defaults.html "> http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/index.jsp? Topic =/com.ibm.java.doc. diagnostics.50/diag/appendixes/defaults.html

JVM Environment Settings

{
Function onclick ()
{
Function onclick ()
{
Pagetracker. _ trackpageview ('/outbound/article/publib.boulder.ibm.com ');
}
}
} "Href =" http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/index.jsp? Topic =/com.ibm.java.doc. diagnostics.50/diag/appendixes/env_var/env_jvm.html "> http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/index.jsp? Topic =/com.ibm.java.doc. diagnostics.50/diag/appendixes/env_var/env_jvm.html

The default heapdumps is disabled, and you should remember to enable it during debugging. The default javadumps on out of memory and heapdumps on out of memory are both enabled, however, the default dump location is the directory where the profile is located. It is best to set ibm_heapdumpdir and ibm_javacoredir to another directory in the Java Process of the Management Console to prevent the dump content from cracking the was file system, affects normal business use.

On a Windows machine, if the memory is greater than 4 GB, remember to enable the/3 GB parameter,In this way, the JVM heap can be set to a greater value, which is close to 2 g-1 (the other three parts can be extended to another 1G), but generally the maximum is no more than 1.7g.

For more details, see {
Function onclick ()
{
Function onclick ()
{
Pagetracker. _ trackpageview ('/outbound/article/publib.boulder.ibm.com ');
}
}
} "Href =" http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/index.jsp "> http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/index.jsp

Or download dig60 {
Function onclick ()
{
Function onclick ()
{
Pagetracker. _ trackpageview ('/outbound/article/www.ibm.com ');
}
}
} "Href =" http://www.ibm.com/developerworks/java/jdk/diagnosis/ "> http://www.ibm.com/?works/java/jdk/diagnosis/#jvm

For Sun's JDK configuration, refer to Java Performance Optimization-sun hotspot jdk jvm parameter settings

 

 

Note:

This article Reprinted from: http://www.hashei.me/2009/05/tuning-the-ibm-jdk.html