Summary of commonly used JVM tuning parameters [feel free to check and learn
The parameters of this article will be continuously updated according to the parameters used at a later stage ---
Indicates setting the minimum value of JVM startup memory to 20M, which must be in M
Indicates setting the maximum value of JVM startup memory to 20M, which must be in M. Setting -Xmx to the same as -Xms will avoid JVM memory auto-scaling. Large projects -Xmx and -Xms are usually set to 10G, 20G or even higher
Indicates the output of the GC details in the virtual machine
indicates that you can set the size of the virtual machine stack to 128k
Indicates setting the size of the local method stack to 128k. However, HotSpot does not distinguish between the VM stack and the local method stack, so this parameter is not valid for HotSpot
Indicates the capacity of the permanent generation (method area) initially allocated by the JVM, which must be in M
Indicates the maximum size of the permanent generation (method area) that the JVM is allowed to allocate, which must be in M. In most cases this parameter defaults to 64M
Indicates turning off the JVM's garbage collection of classes
Indicates viewing class loading information
Indicates viewing class uninstall information
indicates the setting of younger generation（ includeEden and twoSurvivor distinguish）/ old age The ratio of the magnitude of1：4， This means that younger generations account for the entire heap of1/5
indicates setting the size ratio of 2 Survivor zones: 1 Eden zone to 2:8, which means that the Survivor zone accounts for 1/5 of the entire young generation, and this parameter defaults to 8
Indicates setting the size of the young generation to 20M
indicates that it is possible for a virtual machine to have a memory overflow exception in timeDump happen proper Snapshot of the heap memory dump before
indicates to let the JVM use the G1 garbage collector
Indicates that GC specific details are printed on the console
Indicates that GC information is printed on the console
indicates that the object is larger than3145728（3M） time Direct access to old age allocation， Here you can only use bytes as units
Indicates that the subject is older than1， Automatic entry into old age, If set to0 if (coming after a conditional clause)， Then the young generation object does not go throughSurvivor distinguish， Directly into the older generation。 For applications where the older generation is more， It can increase efficiency。 If this value is set to a larger value， Then the young generation object will be inSurvivor Zone for multiple replication， This increases the survival of the object in younger generations time room， Increase the probability of being recycled in younger generations。
Indicates that a method was called1000 next time， It will be considered a hot code， and triggers namely time compile
indicates that you can see the heap memory layout before and after each GC
Indicates that you can see the use of TLAB
Open the spin lock
Change the spin count of the spinlock, to use this parameter you must first turn on the spinlock
indicates the use of jvm's serial garbage collection mechanism, which is applicable to the Dan cpu environment
indicates the use ofjvm The parallel garbage collection mechanism of， The mechanism is suitable for use with multiplecpu machine processed， same time respond to time In an environment where there are no mandatory requirements between， use-XX:ParallelGCThreads=<N> Set the number of threads for parallel garbage collection， This value can be set equal to the number of machine processors。
indicates that the aged generation uses a parallel garbage collection mechanism
Indicates the use of the concurrent mode garbage collection mechanism， This mode is applicable to responses to time High spatial requirements， possess multiplecpu in the context of
Set the maximum 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， The parallel collector will Automatic selection of the young generation zone size and the corresponding Survivor zone ratio， to achieve the minimum response specified by the target system time intervals or collection frequencies, etc.， This value is recommended to use the parallel collector time， Keep it open.
********************************************************************************************************************** divider line **********************************************************************************************************************
Meaning of JVM parameters.
Initial Heap Size
1/64th of the physical memory(<1GB)
default(MinHeapFreeRatio Parameters can be adjusted) Free heap memory is less than40% time，JVM It will increase the heap until-Xmx Maximum limit of the.
Maximum Heap Size
1/4 of physical memory(<1GB)
Default (MaxHeapFreeRatio parameter can be adjusted) When free heap memory is greater than 70%, the JVM will reduce the heap until the -Xms minimum limit
Young generation size (1.4or lator)
Note: The size here is (eden+ 2 survivor space). which is different from the New gen shown in jmap -heap. Whole heap size = young generation size + old generation size + persistent generation size. Increasing the size of the young generation will reduce the size of the old generation. This value has a large impact on system performance, and the official Sun recommendation is 3/8 of the entire heap.
Set young generation size (for 1.3/1.4)
Young Generation Maximum (for 1.3/1.4)
Set the initial value of the persistent generation (perm gen)
1/64th of the physical memory
Set persistent generation maximum
1/4 of physical memory
Stack size per thread
JDK5.0 The subsequent per-thread stack size is1M, Previously the per-thread stack size was256K. The memory size required for more application-specific threads is performed adapt. With the same physical memory, Decreasing this value will generate more threads. But the operating system still has a limit on the number of threads within a process, Cannot be generated indefinitely, The value of experience in3000~5000 Around generally small applications， If the stack is not very deep， It should be.128k suffice Large applications are recommended to use256k。 This option has a greater impact on performance， Rigorous testing required。（ principals） harmonythreadstacksize The options are interpreted very similarly, The official documentation doesn't seem to explain, There is this quote in the forum:"”-Xss is translated in a VM flag named ThreadStackSize” Usually setting this value is sufficient。
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.]
Ratio of younger generations (including Eden and the two Survivor zones) to older generations (excluding persistent generations)
-XX:NewRatio=4 means that the ratio of younger to older generations is 1:4, with younger generations accounting for 1/5 of the entire stack Xms=Xmx and Xmn is set, this parameter does not need to be set.
Ratio of the size of the Eden zone to the Survivor zone
Set to 8, then the ratio of two Survivor zones to one Eden zone is 2:8, and one Survivor zone accounts for 1/10 of the entire young generation
The memory page size should not be set too large, it will affect the size of the Perm
Rapid optimization of original types
This parameter needs to be rigorously tested
Maximum age of garbage
If set to0 if (coming after a conditional clause), Then the young generation object does not go throughSurvivor distinguish, Directly into the older generation. For applications where the older generation is more, It can increase efficiency. If this value is set to a larger value, Then the young generation object will be inSurvivor Zone for multiple replication, This will increase the survival of the object in the younger generation time room, Increasing the probability of being recycled at younger generations This parameter is only available in serialGC time It's only effective..
Performance improvements in the locking mechanism
Disable garbage collection
per trillion of free space in the heapSoftReference survivorship time room
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
Objects over how big are directly assigned in the old generation
unit byte The new generation usesParallel Scavenge GC time Invalid The other case of direct allocation in the old generation is large array objects, and there are no external reference objects in the array.
TLAB as a percentage of eden area
FullGC time whether or notYGC
Parallel collector related parameters.
Full GC using parallel MSC (this is to be verified)
Select the garbage collector as a parallel collector. This configuration is only valid for younger generations. That is, in the above configuration, the younger generation uses concurrent collection, while the older generation still uses serial collection. (This is to be verified)
Set the young generation to collect in parallel
Can be used with CMS collection at the same time JDK5.0 or above, JVM will set itself according to the system configuration, so there is no need to set this value again
Number of threads in the parallel collector
This value should ideally be configured to be equal to the number of processors The same applies to CMS
Parallel Compacting is the old generation garbage collection method
This is the parameter option that appears in JAVA 6
The longest per young generation garbage collection time room( Maximum Pause time room)
If this time cannot be met, the JVM will automatically adjust the size of the young generation to meet this value.
Automatic selection of the young generation zone size and the corresponding Survivor zone ratio
After setting this option, The parallel collector will Automatic selection of the young generation zone size and the corresponding Survivor zone ratio, to meet the minimum corresponding time intervals or collection frequencies, etc., This value is recommended to use the parallel collector time, Keep it open..
Setting up garbage collection time inter-occupancy program running time Percentage between
The formula is 1/(1+n)
Call YGC before Full GC
Do young generation GC prior to a full GC. (Introduced in 1.4.1.)
Using CMS Memory Collection
After configuring this in the test,-XX:NewRatio=4 The configuration of the, The reason is unknown.. consequently, this time Young generation size works best-Xmn set up.???
The attempt is to use a lot of physical memory long time Optimization of large memory usage between， Ability to check computing resources（ RAM， Number of processors） You need at least256MB The memory is heavilyCPU／ RAM， （ (located) at1.4.1 (located) at4CPU on the machines that already show a boost）
How many times after memory compression
Since concurrent collectors do not compress memory space, collate (data, files), So running a section of time The interval will later produce" debris", Makes operation less efficient. This value sets how many times to runGC Compressing memory space later, collate (data, files).
Lower the marker pause
(located) atFULL GC of time wait， Compression of older generations
CMS It won't move the memory.， therefore， This one is very fragile.， Causes insufficient memory， therefore， Memory compression of this time The system will be enabled when。 It's a good habit to add this parameter。 May affect performance, But the debris can be removed
Start CMS collection using manual definition initialization definition
Disable hostspot from triggering CMS GC on its own
Use cms as garbage collection using 70% after starting CMS collection
To ensure that the promotion failed (see below) error does not occur, the value needs to be set to satisfy the following formula CMSInitiatingOccupancyFraction calculation formula
set upPerm Gen What rate is reached using time trigger
Set to incremental mode
For single CPU cases
Output form: [GC 118250K->113543K(130112K), 0.0094143 secs][Full GC 121376K->10414K(130112K), 0.0650971 secs]
Output form:[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 secs]
Available with-XX:+PrintGC -XX:+PrintGCDetails Mixed use Output form:11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]
The program is paused during print garbage collection time room. Can be mixed with the above
Output form:Total time for which application threads were stopped: 0.0468229 seconds
Print the uninterrupted execution time of the program before each garbage collection. Can be mixed with above
Output form:Application time: 0.5291524 seconds
Print detailed stack information before and after GC
Logging relevant log information to a file for analysis. Used in conjunction with the above
garbage collects before printing the histogram.
View TLAB space usage
Check the threshold of the new survival cycle after each minor GC
Desired survivor size 1048576 bytes, new threshold 7 (max 15) new threshold 7 i.e. the threshold value that identifies a new survivor cycle is 7.
GC performance considerations
aboutGC the performance of the main2 indicators of the aspect： throughputthroughput（ Job time Doesn't countgc of time accounted for time Ratio） and pausepause（gc happen timeapp The external display is not responding）。
1. Total Heap
By default, vm increases/decreases the heap size to maintain the proportion of free space in the entire vm, which is specified by MinHeapFreeRatio and MaxHeapFreeRatio.
In general, the server-side app will have the following rules.
2. The Young Generation
Another factor that has an impact on how smoothly the app runs is the size of the young generation. The larger the young generation, the smaller the minor collection; but with a fixed heap size, a larger young generation means a smaller tenured generation, which means more major collections (major collections trigger 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, and setting these two values to the same value fixes the size of the young generation (the same as Xms and Xmx).
SurvivorRatio can also optimize the size of the survivor if desired, though this does not have a significant impact on performance. SurvivorRatio is the ratio of eden to survior size.
In general, the server-side app will have the following rules.
Garbage collection timepromotion failed It's a headache， There are generally two possible causes， The first reason is that there is not enough room for rescue， Objects in the rescue space should not be moved to the older generation， But the younger generation has a lot of objects to put into the rescue space； The second reason is that older generations do not have enough space to accommodate objects from the younger generation；
Both cases will turnFull GC， The site pauses time longer。
The first reason my final solution was to remove the salvage space and just set -XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0.
The second reason my solution is setupCMSInitiatingOccupancyFraction is a value（ hypothesis70）， Such an old generation of space to70% time Start executingCMS， The older generation has enough room to accept objects from the younger generation。
There has been an improvement， The above method is not very good， Because the salvage space was not used， So older generations tend to be full，CMS Implementation will be more frequent。 I've improved it.， Still using salvage space， But increase the salvage space， And that way there will be nopromotion failed。 specifically speaking，32 bitLinux harmony64 bitLinux It doesn't seem to be the same，64 Bit systems seem to be configured as long as 1MaxTenuringThreshold parameter，CMS There is still a pause。 In order to resolve the pause issue andpromotion failed issue， Finally I set-XX:SurvivorRatio=1 ， and put itMaxTenuringThreshold remove， This means that there is no pause and there will be nopromotoin failed， And more importantly， The rise of older and permanent generations is very slow（ Because a lot of objects can't get to old age and they're recycled）， consequentlyCMS The frequency of execution is very low， Several small time only once， such， The server doesn't have 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
It's described abovepromontion faild The reason for this isEDEN In the case of insufficient space will beEDEN andFrom survivor The surviving object in is depositedTo survivor distinguish time,To survivor Insufficient space in the district， Promoted again toold gen distinguish， but (not)old gen Zone memory is also insufficient to generatepromontion faild thereby leading tofull gc. Then it can be inferred that：eden+from survivor < old gen Zone Remaining Memory time， will not appearpromontion faild situation， namely： (Xmx-Xmn)*(1-CMSInitiatingOccupancyFraction/100)>=(Xmn-Xmn/(SurvivorRatior+2)) And then infer：
properxmx=128 xmn=36 SurvivorRatior=1 time CMSInitiatingOccupancyFraction<=((128.0-36)-(36-36/(1+2)))/(128-36)*100 =73.913
properxmx=128 xmn=24 SurvivorRatior=1 time CMSInitiatingOccupancyFraction<=((128.0-24)-(24-24/(1+2)))/(128-24)*100=84.615…
properxmx=3000 xmn=600 SurvivorRatior=1 time CMSInitiatingOccupancyFraction<=((3000.0-600)-(600-600/(1+2)))/(3000-600)*100=83.33
CMSInitiatingOccupancyFraction below 70% Requires adjustment of xmn or SurvivorRatior values.