JVM series three: JVM parameter setting and analysis

http://www.cnblogs.com/redcreen/archive/2011/05/04/2037057.html#CMSInitiatingOccupancyFraction_value

http://www.cnblogs.com/redcreen/archive/2011/05/04/2037029.html



redcreen Column

    News
    Contact
    Management
    Subscription

JVM Series III: JVM Parameter Setting and Analysis

       Whether it is YGC or Full GC, the GC process will cause interruptions in the running of the program. Correctly choosing different GC strategies and adjusting the parameters of JVM and GC can greatly improve the Reduce the problem of program interruption due to GC work, and then appropriately improve the work efficiency of Java programs. However, adjusting GC is an extremely complicated process, because each program has different characteristics, such as: web and GUI programs are very different (Web can be paused properly, but GUI pauses are unacceptable to customers), and due to running The configuration on each machine is different (mainly the number of cups, the memory is different), so the type of GC used will also be different (for how to choose, see GC type and how to choose). This article will focus on introducing the settings of some important parameters of JVM and GC to improve the performance of the system.

       For JVM memory composition and GC related content, please refer to the previous article: JVM memory composition GC strategy & memory application.

For an example of the meaning of JVM parameters, see Example Analysis.
Parameter name meaning Default value
-Xms Initial heap size 1/64 of physical memory (<1GB) Default (MinHeapFreeRatio parameter can be adjusted) When the free heap memory is less than 40%, the JVM will increase the heap until -Xmx maximum limit.
-Xmx Maximum heap size 1/4 of physical memory (<1GB) Default (MaxHeapFreeRatio parameter can be adjusted) When the free heap memory is greater than 70%, the JVM will reduce the heap until the minimum limit of -Xms
-Xmn young generation size (1.4or lator)
  Note: The size here is (eden+ 2 survivor space). It is different from the New gen shown in jmap -heap.
The size of the entire heap = young generation size + old generation size + persistent generation size.
After increasing the young generation, the size of the old generation will be reduced. This value has a great impact on system performance, and Sun officially recommends setting it to 3 for the entire heap. /8
-XX:NewSize Set the size of the young generation (for 1.3/1.4)  
-XX:MaxNewSize The maximum value of the young generation (for 1.3/1.4)  
-XX:PermSize Set the initial value of the persistent generation (perm gen) 1/64 of the physical memory
- XX:MaxPermSize Set the persistent generation maximum value of 1/4 of physical memory
-Xss The stack size of each thread After JDK5.0, the stack size of each thread is 1M, and the previous stack size of each thread is 256K. More application threads need Adjust the memory size. Under the same physical memory, reducing this value can generate more threads. However, the operating system still has a limit on the number of threads in a process, which cannot be generated indefinitely. The experience value is
generally For applications, if the stack is not very deep, 128k should be enough for large applications, and 256k is recommended. This option has a large performance impact and requires rigorous testing. (Principal)
is very similar to the explanation of the threadstacksize option, the official document seems to have no explanation, there is such a sentence in the forum: ""
-Xss is translated in a VM flag named ThreadStackSize"
is generally enough to set this value.
-XX:ThreadStackSize Thread Stack Size (0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.]
-XX:NewRatio ratio of young generation (including Eden and two survivor areas) to old generation (excluding Persistent generation) -XX:NewRatio=4 indicates that the ratio between the young generation and the old generation is 1:4, and the young generation accounts for 1/5 of the entire stack
Xms=Xmx and Xmn is set, this parameter does not need to be set -XX:SurvivorRatio The
size ratio of Eden area to Survivor area is set to 8, then the ratio of two Survivor areas to one Eden area is 2:8, and one Survivor area accounts for 1/10 of the entire young generation
-XX:LargePageSizeInBytes memory pages The size cannot be set too large, it will affect the size of Perm=128m
-XX:+UseFastAccessorMethods Fast optimization of primitive types  
-XX:+DisableExplicitGC Close System.gc() This parameter requires strict testing
-XX:MaxTenuringThreshold If the maximum age of garbage is set to 0, the young generation objects directly enter the old generation without passing through the Survivor area. For applications with many old generations, the efficiency can be improved. If this value is set to a larger value value, the young generation object will be replicated multiple times in the Survivor area, which can increase the survival time of the object in the young generation and increase the probability of being recycled in the young generation.
This parameter is only valid in serial GC.
-XX:+ AggressiveOpts to speed up compilation  
-XX:+UseBiasedLocking performance improvement for locking mechanism  
-Xnoclassgc to disable garbage collection  
-XX:SoftRefLRUPolicyMSPerMB SoftReference survival time per mega heap free space 1s softly reachable objects will remain alive for some amount of time after the last time they were referenced. The default value is one second of lifetime per free megabyte in the heap
-XX:PretenureSizeThreshold The size of the object is directly allocated 0 unit bytes in the old generation. It is invalid when the new generation adopts Parallel Scavenge GC. The
other is directly in the old generation. The allocation situation is a large array object, and there are no external reference objects in the array.
-XX:TLABWasteTargetPercent TLAB accounts for 1% of the eden area
-XX:+CollectGen0First FullGC whether to first YGC false

Parallel collector related parameters
-XX:+UseParallelGC Full GC uses parallel MSC
(this item to be verified)  

to select the garbage collector as the parallel collector. This configuration is only valid for the young generation. That is, under the above configuration, the young generation uses concurrent collection, while The old generation still uses serial collection. (This item is to be verified)
-XX:+UseParNewGC Set the young generation to parallel collection. It can use
JDK5.0 or higher at the same time as the CMS collection. The JVM will set it according to the system configuration, so there is no need to set this value.
-XX:ParallelGCThreads The number of parallel collector threads This value is best configured to be equal to the number of processors. It is also applicable to CMS
-XX:+UseParallelOldGC The old generation garbage collection method is Parallel Compacting This is a parameter option that appears in JAVA 6 -XX: MaxGCPauseMillis
The maximum time (maximum pause time) for each young generation garbage collection. If this time cannot be met, the JVM will automatically adjust the young generation size to meet this value.
After setting this option for the corresponding Survivor area ratio, the parallel collector will automatically select the size of the young generation area and the corresponding Survivor area ratio to achieve the minimum corresponding time or collection frequency specified by the target system. This value is recommended when using the parallel collector. Always open.
-XX:GCTimeRatio Set the percentage of garbage collection time to program running time The formula is 1/(1+n)
-XX:+ScavengeBeforeFullGC Call YGC true Do young generation GC prior to a full GC. (Introduced in 1.4.1.)

CMS related parameters
-XX:+UseConcMarkSweepGC Use CMS memory collection test after configuring this, -XX: The configuration of NewRatio=4 is invalid, and the reason is unknown. Therefore, it is best to use
-Xmn to set the size of the young generation at this time.???
Computational resources (memory, number of processors)
require at least 256MB of memory A
lot of CPU/memory, (in 1.4.1 has shown improvement on 4CPU machines)
-XX:CMSFullGCsBeforeCompaction how many times to perform memory compression due to concurrent collectors The space is compressed and sorted, so "fragmentation" will be generated after running for a period of time, which will reduce the running efficiency. This value sets how many times the GC is run to compress and sort the memory space.
-XX:+CMSParallelRemarkEnabled Reduce marking pause  
-XX+UseCMSCompactAtFullCollection During FULL GC, the compression CMS for the old generation will not move the memory. Therefore, it is very easy to generate fragmentation, resulting in insufficient memory. Therefore, memory compression will be enabled at this time. It is a good practice to increase this parameter.
May affect performance, but can eliminate fragmentation
-XX:+UseCMSInitiatingOccupancyOnly Start CMS collection with manually defined initialization definitions Disable hostspot from triggering CMS GC by itself
-XX:CMSInitiatingOccupancyFraction=70 Use cms as garbage collection Start CMS collection 92 after
using 70% to ensure that there is no promotion failed (see below) error , The setting of this value needs to meet the following formula CMSInitiatingOccupancyFraction calculation formula
-XX:CMSInitiatingPermOccupancyFraction Set how much ratio Perm Gen uses to trigger 92
-XX:+CMSIncrementalMode Set to incremental mode for single CPU case
-XX:+CMSClassUnloadingEnabledAuxiliary    

information
-XX :+PrintGC    

output format:

[GC 118250K->113543K(130112K), 0.0094143 secs]
[Full GC 121376K->10414K(130112K), 0.0650971 secs]
-XX:+PrintGCDetails    

output format: [GC [DefNew: 8614K->781K] (9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs]
[GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K+(130112K), 0.0436268 secsTime :+Print GCStamps
-XX:+    
Print PrintGC:PrintGCTimeStamps can be mixed with -XX:+PrintGC -XX:+PrintGCDetails
Output format: 11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]
-XX:+PrintGCApplicationStoppedTime Prints the time the program was paused during garbage collection. Yes Mixed with the above output form: Total time for which application threads were stopped: 0.0468229 seconds
-XX:+PrintGCApplicationConcurrentTime Prints the uninterrupted execution time of the program before each garbage collection. Can be mixed with the above Output form: Application time: 0.5291524 seconds
-XX:+PrintHeapAtGC Print detailed stack information before and after GC  
-Xloggc:filename Record relevant log information to a file for analysis. Use in
conjunction with the above  

-XX:+PrintClassHistogram
garbage collects before printing the histogram.  
-XX:+PrintTLAB View the TLAB space usage  
XX:+PrintTenuringDistribution View the threshold of the new survival cycle after each minor GC  

Desired survivor size 1048576 bytes, new threshold 7 (max 15)
new threshold 7 That is, the threshold value for identifying a new life cycle is 7.

GC performance considerations

       There are two main indicators of GC performance: throughput (the ratio of the working time not counting the time of gc to the total time) and pause (the app cannot respond to the external display when gc occurs).

1. Total Heap

       By default, the vm will increase/decrease the heap size to maintain the proportion of free space in the entire vm, which is specified by MinHeapFreeRatio and MaxHeapFreeRatio.

Generally speaking, the app on the server side will have the following rules:

    allocate as much memory as possible to the vm;
    set Xms and Xmx to the same value. If the memory used by the virtual machine is relatively small when it is started, and many objects need to be initialized at this time, the virtual machine must repeatedly increase the memory.
    As the number of processor cores increases, so does the memory.

2. The Young Generation

       Another factor that affects the smooth running of the app is the size of the young generation. The larger the young generation, the less the minor collection; but in the case of a fixed heap size, a larger young generation means a smaller tenured generation, which means more major collections (major collections will lead to minor collections).

       NewRatio reflects the size ratio of young and tenured generation. NewSize and MaxNewSize reflect the lower and upper limits of the young generation size. Setting these two values ​​to the same fixes the young generation size (same as Xms and Xmx).

       SurvivorRatio can also optimize the size of survivors if desired, but this has little impact on performance. SurvivorRatio is the ratio of eden and survivor size.

Generally speaking, the app on the server side will have the following rules:

    first determine the maximum heap size that can be allocated to the vm, and then set the optimal young generation size;
    if the heap size is fixed, increasing the size of the young generation means reducing the size of the young generation. Tenured generation size. Make the tenured generation large enough to hold all live data at any time (leave 10%-20% free).

Experience && Rules

    Young Generation Size Selection
        Response time priority application: set as large as possible until it is close to the minimum response time limit of the system (selected according to the actual situation). In this case, the frequency of young generation collection is also the smallest. At the same time, reduce the number of times that reach the old generation Object.
        Applications with throughput priority: set as large as possible, possibly reaching the level of Gbit. Because there is no requirement for response time, garbage collection can be performed in parallel, which is generally suitable for applications with more than 8 CPUs.
        Avoid setting too small. When the new generation is set Hour will lead to: 1. The number of YGC is more frequent 2. It may cause the YGC object to directly enter the old generation. If the old generation is full at this time, FGC will be triggered.
    The size of the old generation selects
        the application with response time priority: use the old generation Concurrent collector, so its size needs to be set carefully. Generally, some parameters such as concurrent session rate and session duration should be considered. If the heap setting is small, it may cause memory fragmentation, high recycling frequency and application suspension, and the traditional mark clear method is used. ;If the heap is large, it will take a long time to collect. The optimal solution generally needs to be obtained by referring to the following data:
        concurrent garbage collection information, the number of concurrent collections in the persistent generation, traditional GC information, and recycling spent in the young and old generations time ratio.
        Throughput-first applications: Generally, throughput-first applications have a large young generation and a small old generation. The reason is that most short-term objects can be recycled as much as possible, reducing medium-term objects, while the annual The old generation stores long-lived objects.
    The fragmentation problem caused by the smaller heap is
    because the concurrent collector of the old generation uses the mark-sweep algorithm, so the heap will not be compressed. When the collector is reclaimed, it will put adjacent space Merge, which can be allocated to larger objects. However, when the heap space is small, after running for a while, there will be "fragmentation", and if the concurrent collector cannot find enough space, the concurrent collector will stop , and then use the traditional mark and clear method for recycling. If "fragmentation" occurs, the following configuration may be required:
    -XX:+UseCMSCompactAtFullCollection: When using the concurrent collector, enable the compression of the old generation.
    -XX:CMSFullGCsBeforeCompaction=0: When the above configuration is enabled, here is how many times of Full GC is set to compress the old generation
    with 64 Bit operating system, 64-bit jdk under Linux is slower than 32-bit jdk, but it eats more memory and has higher throughput
    . The
    advantage of using CMS is to use as few young generations as possible, and the experience value is 128M-256M, and then use CMS to collect the old generation in parallel, which can ensure the low-latency throughput efficiency of the system. In fact, the collection pause time of cms is very short, the memory of 2G, the application pause time of about 20-80ms. When the
    system pauses, it may be a GC problem or a program problem. Use jmap and jstack to check, or killall -3 java, and then check the java console log, you can see a lot of problems. (The usage of related tools will be introduced in a later blog.)
    Learn about your application carefully. If you use a cache, the old generation should be larger, and the cached HashMap should not be infinitely long. It is recommended to use the LRU algorithm Map as the cache , the maximum length of LRUMap should also be set according to the actual situation.
    When using concurrent recycling, the young generation is smaller, and the old generation is larger, because the old generation uses concurrent recycling, even if it takes a long time, it will not affect the continued operation of other programs, and the website will not stop
    There is no fixed formula for the setting of JVM parameters (especially –Xmx –Xms –Xmn -XX:SurvivorRatio -XX:MaxTenuringThreshold and other parameters, which need to be measured according to the actual data YGC times in the PV old area. In order to avoid promotion faild It may cause the xmn setting to be too small, which also means that the number of YGCs will increase, and the ability to handle concurrent access will decrease. The adjustment of each parameter requires detailed performance testing to find the best configuration for a specific application.

promotion failed :

promotion failed during garbage collection is a very headache problem. Generally, there may be two reasons. The first reason is that the rescue space is not enough. The objects in the rescue space should not be moved to the old generation, but there are many young generation. The object needs to be put into the rescue space; the second reason is that the old generation does not have enough space to accept the object from the young generation; both cases will turn to Full GC, and the website will be paused for a long time.

Solution 1:

The first reason My final solution is to remove the rescue space and set -XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0. For the second reason, my solution is to set CMSInitiatingOccupancyFraction to a certain value (assuming 70), so that the old generation When the space reaches 70%, the CMS will be executed, and the old generation has enough space to accept objects from the young generation.

Improvement of solution 1:

There are improvements. The above method is not very good, because the rescue space is not used, so the old generation is easy to be full, and the CMS execution will be more frequent. I improved it a bit, still use the rescue space, but increase the rescue space, so there will be no promotion failed. In terms of specific operations, 32-bit Linux and 64-bit Linux seem to be different. It seems that the 64-bit system only needs to configure the MaxTenuringThreshold parameter, and the CMS still pauses. In order to solve the problem of pause and promotion failed, I finally set -XX:SurvivorRatio=1 and removed MaxTenuringThreshold, so that there is no pause and no promotoin failure, and more importantly, the old generation and permanent generation rise very slowly (Because many objects are recycled before they reach the old generation), the CMS execution frequency is very low, only once every few hours, so that the server does not need to be restarted.

-Xmx4000M -Xms4000M -Xmn600M -XX:PermSize=500M -XX:MaxPermSize=500M -Xss256K -XX:+DisableExplicitGC -XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:LargePageSizeInBytes=128M -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=80 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log



CMSInitiatingOccupancyFraction值与Xmn的关系公式

The reason for the promontion faild is described above. When the EDEN and From survivor objects are stored in the To survivor area when the EDEN space is insufficient, the space in the To survivor area is insufficient, and it is promoted to the old gen area again, while the memory in the old gen area is If it is not enough, promontion faild will be generated, resulting in full gc. It can be inferred that: when eden+from survivor < the remaining memory in the old gen area, promontion faild will not occur, that is:
(Xmx-Xmn)*(1- CMSInitiatingOccupancyFraction/100)>=(Xmn-Xmn/(SurvivorRatior+2)) and then infer:

CMSInitiatingOccupancyFraction <=((Xmx-Xmn)-(Xmn-Xmn/(SurvivorRatior+2)))/(Xmx-Xmn)* 100

For example:

when xmx=128 xmn=36 SurvivorRatior=1, CMSInitiatingOccupancyFraction<=((128.0-36)-(36-36/(1+2)))/(128-36)*100 =73.913

when xmx=128 When xmn=24 SurvivorRatioor=1 CMSInitiatingOccupancyFraction<=((128.0-24)-(24-24/(1+2)))/(128-24)*100=84.615...

when xmx=3000 xmn=600 SurvivorRatior=1 When CMSInitiatingOccupancyFraction<=((3000.0-600)-(600-600/(1+2)))/(3000-600)*100=83.33

CMSInitiatingOccupancyFraction is lower than 70%, the xmn or SurvivorRatior value needs to be adjusted.

Order:

The formula inferred by a child's shoe on the Internet is: (Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn This formula is not very rigorous in my opinion, and it will affect the calculation of xmn when the memory is small.



For the configuration of GC parameters in the actual environment, see: Instance analysis. For monitoring tools, see JVM monitoring

. Reference :

JAVA HOTSPOT VM (http://www.helloying.com/blog/archives/164)

Several important parameters of JVM (principal)

java jvm parameters -Xms -Xmx -Xmn -Xss Tuning Summary

Java HotSpot VM Options

http://bbs.weblogicfans.net/archiver/tid-2835.html

Frequently Asked Questions About the Java HotSpot VM

Java SE HotSpot at a Glance

Java Performance Tuning Notes (with test examples are useful) to

talk about the parameter MaxTenuringThreshold



Related article recommendation:

Summary of GC tuning methods

Java 6 JVM parameter options (Chinese version)
redcreen