JVM Series three: JVM parameter settings, analysis

JVM Memory composition and GC-related content see previous articles: JVM memory composition GC Policy & memory request.

Example of the meaning of JVM parameters is shown in example analysis

Parameter name	Meaning	Default value
-xms	Initial Heap Size	1/64 of physical Memory (<1GB)	The default (minheapfreeratio parameter can be adjusted) when the free heap memory is less than 40%, the JVM increases the heap until the maximum limit of-xmx.
-xmx	Maximum Heap Size	Physical memory of the quarter (<1GB)	The default (maxheapfreeratio parameter can be adjusted) when the free heap memory is greater than 70%, the JVM reduces 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 entire heap size = younger generation size + old generation size + persistent generation size. Increasing the younger generation will reduce the size of older generations. This value has a large impact on system performance, and Sun is the official recommended configuration for the entire heap of 3/8
-xx:newsize	Set the young generation size (for 1.3/1.4)
-xx:maxnewsize	Young generation Max (for 1.3/1.4)
-xx:permsize	Set the persistence generation (Perm Gen) initial value	1/64 of physical memory
-xx:maxpermsize	Set Persistent generation maximum value	1/4 of physical memory
-xss	stack size for each thread		After JDK5.0, each thread has a stack size of 1M, before each thread has a stack size of 256K. The size of the memory required for the thread to be applied is adjusted. In the same physical memory, reducing this value can generate more threads. However, the operating system has a limit on the number of threads in a process and cannot be generated indefinitely. Experience value is around 3000~5000 Generally small applications, if the stack is not very deep, should be 128k enough for large applications recommended using 256k. This option has a large impact on performance and requires rigorous testing. Principal Similar to the Threadstacksize option interpretation, the official documentation does not seem to explain the phrase in the Forum: "" -XSS is translated in a VM flag named Threadstacksize " The general setting of this value is available.
-xx:threadstacksize	Thread Stack Size		(0 means use default stack size) [sparc:512; Solaris x86:320 (was-prior in 5.0 and earlier); Sparc bit:1024; Linux amd64:1024 (was 0 in 5.0 and earlier); All others 0.]
-xx:newratio	Ratio of young generations (including Eden and two survivor districts) to older generations (excluding persistent generations)		-xx:newratio=4 says the ratio of young generations to older generations is 1:4, and the younger generation accounts for 1/5 of the entire stack. Xms=xmx and the xmn is set, this parameter does not need to be set.
-xx:survivorratio	The ratio of the Eden area to the survivor area		Set to 8, the ratio of two survivor to one Eden area is 2:8, and a survivor area represents 1/10 of the entire young generation.
-xx:largepagesizeinbytes	The size of the memory page cannot be set too large, affecting the size of the perm		=128m
-xx:+usefastaccessormethods	Rapid optimization of primitive types
-xx:+disableexplicitgc	Close System.GC ()		This parameter requires rigorous testing.
-xx:maxtenuringthreshold	Maximum age of garbage		If set to 0, then the young generation object does not go through the survivor area, directly into the old generation. For older generations of more applications, can improve efficiency. If you set this value to a larger value, the younger generation object will replicate multiple times in the Survivor area, which increases the lifetime of the object's younger generations, increasing the probability of being recycled in the younger generation. This parameter is valid only when the serial GC is in effect.
-xx:+aggressiveopts	Faster compilation
-xx:+usebiasedlocking	Performance improvement of lock mechanism
-xnoclassgc	Disable garbage collection
-xx:softreflrupolicymspermb	SoftReference survival time in free space per megabyte of heap	1s	Softly reachable objects would 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	Objects more than how large are directly allocated in the old generation	0	Unit bytes Invalid When using parallel scavenge GC for Cenozoic Another case that is allocated directly in the old generation is a large array object, and there are no externally referenced objects in the array.
-xx:tlabwastetargetpercent	Tlab% of Eden area	1%
-xx:+Collectgen0first	Whether to YGC first when FULLGC	False

Parallel Collector related Parameters

-xx:+useparallelgc	Full GC with parallel MSC (This is to be verified)		Select the garbage collector as the parallel collector. This configuration is valid only for younger generations. That is, the younger generation uses concurrent collection, while older generations still use serial collection. (This is to be verified)
-xx:+useparnewgc	Set Young on behalf of the parallel collection		Can be used together with CMS collection JDK5.0 above, the JVM will set itself according to the system configuration, so it is no longer necessary to set this value
-xx:parallelgcthreads	Number of threads in the parallel collector		This value is best configured equal to the number of processors equally applicable to the CMS
-xx:+useparalleloldgc	Old Generation garbage collection method for parallel collection (Parallel compacting)		This is the parameter option that appears in Java 6
-xx:maxgcpausemillis	Maximum time for each young generation of garbage collection (max pause time)		If this time is not met, the JVM automatically adjusts the young generation size to meet this value.
-xx:+useadaptivesizepolicy	Automatic selection of the size of the young generation and corresponding survivor area ratio		When this option is set, the parallel collector automatically selects the size of the young generation area and the corresponding Survivor area scale to achieve the minimum corresponding time specified by the target system, or the collection frequency, which is recommended to be turned on when using the parallel collector.
-xx:gctimeratio	Set garbage collection time as a percentage of program run time		The formula is 1/(1+n)
-xx:+SCAVENGEBEFOREFULLGC	Call YGC before full GC	True	Do young generation GC prior to a full GC. (introduced in 1.4.1.)

CMS Related parameters

-xx:+useconcmarksweepgc	Using CMS Memory Collection		After configuring this in the test, the configuration of the-xx:newratio=4 is invalidated and the cause is unknown. So, at this time the younger generation size is best set with-xmn.???
-xx:+aggressiveheap			Trying to use a lot of physical memory Optimized for long-time large memory usage, can check compute resources (memory, number of processors) Requires at least 256MB of memory A large amount of cpu/memory, (which has been shown to have increased in 1.4.1 on a 4CPU machine)
-xx:cmsfullgcsbeforecompaction	How many times after the memory compression		Because the concurrent collector does not compress the memory space, it will result in "fragmentation" after running for a period of time, resulting in reduced operational efficiency. This value sets the number of times the GC runs after the memory space is compressed and organized.
-xx:+cmsparallelremarkenabled	Reduce Mark pauses
-xx+usecmscompactatfullcollection	In full GC, the compression of older generations		CMS does not move memory, so this is very prone to fragmentation, resulting in insufficient memory, so memory compression will be enabled at this time. It's a good habit to add this parameter. Performance may be affected, but fragmentation can be eliminated
-xx:+usecmsinitiatingoccupancyonly	Start the CMS collection using the manual definition initialization definition		Prohibit Hostspot self-triggering of CMS GC
-xx:cmsinitiatingoccupancyfraction=70	Using CMS as garbage collection Start CMS collection after using 70%	92	To ensure that the promotion failed (see below) error does not appear, the setting for this value needs to meet the following formula cmsinitiatingoccupancyfraction calculation Formula
-xx:cmsinitiatingpermoccupancyfraction	Trigger when setting perm Gen usage to reach how much ratio	92
-xx:+cmsincrementalmode	Set to incremental mode		For single CPU conditions
-xx:+cmsclassunloadingenabled

Ancillary information

-xx:+printgc			Output form: [GC 118250k->113543k (130112K), 0.0094143 secs] [Full GC 121376k->10414k (130112K), 0.0650971 secs]
-xx:+printgcdetails			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]
-xx:+printgctimestamps
-xx:+printgc:printgctimestamps			Can be mixed with-xx:+printgc-xx:+printgcdetails Output form: 11.851: [GC 98328k->93620k (130112K), 0.0082960 secs]
-xx:+printgcapplicationstoppedtime	The time the program was paused during the print garbage collection. Can be mixed with the above		Output form: Total time for which application threads were stopped:0.0468229 seconds
-xx:+printgcapplicationconcurrenttime	The execution time that the program was not interrupted before printing each garbage collection. Can be mixed with the above		Output form: Application time:0.5291524 seconds
-xx:+printheapatgc	Detailed stack information before and after printing the GC
-xloggc:filename	Logs the relevant log information to a file for analysis. Use with the above several mates
-xx:+printclasshistogram	Garbage collects before printing the histogram.
-xx:+printtlab	View the usage of Tlab space
Xx:+printtenuringdistribution	View thresholds for new survival cycles after each minor GC		Desired survivor size 1048576 bytes, new threshold 7 (max 15) New Threshold 7 identifies a threshold value of 7 for the newly-lived cycle.

GC Performance Considerations

There are 2 main metrics for GC performance: Throughput throughput (the total time spent in the GC is not counted) and pause pauses (the app is not responding when the GC occurs).

1. Total Heap

By default, the VM increases/decreases the heap size to maintain the percentage of free space throughout the VM, as specified by Minheapfreeratio and Maxheapfreeratio.

Generally, server-side apps have the following rules:

• Allocate as much memory as possible to the VM;
• Set XMS and Xmx to the same value. If the virtual machine is set to use less memory when it starts, and it needs to initialize many objects at this time, the virtual machine must increase the memory repeatedly.
• The number of processor cores increases and the memory increases.

2. The young Generation

Another factor affecting the smooth running of the app is the size of young generation. The larger the young generation, the less the minor collection, but in the case of fixed heap size, the larger younger generation means a small tenured generation, which means more major Collection (Major collection will cause minor collection).

Newratio reflects the size ratio of young and tenured generation. NewSize and maxnewsize reflect the lower and upper limits of the size of young generation, setting these two values to the same size as the young generation (same as XMS and XMX).

If you want, survivorratio can also optimize the size of the survivor, but this does not have a significant impact on performance. Survivorratio is the Eden and Survior size ratio.

Generally, server-side apps have the following rules:

• First decide the largest heap size that can be assigned to the VM, and then set the optimal size of young generation;
• If the heap size is fixed, increasing the size of young generation means reducing the tenured generation size. Make tenured generation big enough to hold all live data (10%-20% free) at any time.

Experience && Rules

2. Young Generation Size Selection
   • Response Time-First application: as large as possible until the minimum response time limit of the system is approached (depending on the actual situation). In such cases, the frequency of collection of young generations is also minimal. At the same time, reduce the reach of older generations of the object.
   • Throughput-First application: as large as possible, can reach Gbit. Because there is no response time required, garbage collection can be done in parallel, generally suitable for more than 8CPU applications.
   • Avoid setting too small. When the new generation is set to hours, it causes: 1.YGC times more frequently 2. The YGC object may be brought directly into the old generation, and if the old generation is full at this time, the FGC will be triggered.
4. Elder Generation Size Selection
   1. Response Time-First application: Older generations use concurrent collectors, so their size needs to be set carefully, and some parameters, such as concurrency session rate and session duration, are generally considered. If the heap setting is small, it can result in memory fragmentation, high recovery frequency, and application pauses using the traditional markup cleanup method; If the heap is large, A longer collection time is required. The most optimized scenario is generally referred to the following data to obtain:
      Concurrent garbage collection information, persistent generation of concurrent collection times, traditional GC information, and time-to-spend on the collection of young and old generations.
   2. Throughput-First applications: General throughput priority applications have a very large young generation and a smaller old generation. The reason is that it is possible to recycle most of the short-term objects, reduce the medium-term objects, and the old generation to store long-term survivors.
6. Fragmentation problems caused by smaller heaps
   Because the old generation of concurrent collectors uses tags to clear the algorithm, the heap is not compressed. When the collector recycles, he merges the adjacent space so that it can be assigned to a larger object. However, when the heap space is small, "fragmentation" occurs after a period of time, if the concurrent collector cannot find enough space , the concurrent collector will stop and then be recycled using the traditional markup and cleanup method. If "Fragmentation" occurs, the following configuration may be required:
   -xx:+usecmscompactatfullcollection: When using the concurrency collector, the compression of older generations is turned on.
   -xx:cmsfullgcsbeforecompaction=0: When the above configuration is on, how many times the full GC is set, the old generation is compressed
8. With a 64-bit operating system, the Linux 64-bit JDK is slower than the 32-bit JDK, but eats more memory and has more throughput
10. Xmx and XMS settings are as large as MaxPermSize and minpermsize settings, which reduces the pressure of the scaling heap size
12. The advantage of using CMS is to use as few new generation as possible, the experience value is 128m-256m, then the Laosheng generation uses the CMS to collect in parallel, which can guarantee the system low latency throughput efficiency. In fact, the CMS collection pause time is very short, 2G of memory, about 20-80MS application pause time
14. When the system pauses may be the GC problem may be the problem of the program, more with Jmap and Jstack view, or killall-3 Java, and then view the Java console log, can see a lot of problems. (The use of related tools will be described in the following blog)
16. Careful understanding of their application, if the use of the cache, then the older generation should be larger, the cache hashmap should not be unlimited long, it is recommended to use the LRU algorithm map cache, the maximum length of lrumap should be set according to the actual situation.
18. The use of concurrent recycling, the younger generation of small, older generations to big, because the eldest brother with the use of concurrent recovery, even if the time will not affect the other programs continue to run, the site will not pause
20. The setting of the JVM parameter (especially the setting of –xmx–xms–xmn-xx:survivorratio-xx:maxtenuringthreshold parameter is not a fixed formula, it needs to be measured according to the number of actual data ygc in PV old area. To avoid promotion faild may cause xmn settings to be small, it also means that the number of YGC will increase, and the ability to handle concurrent access is reduced. The tuning of each parameter requires detailed performance testing to find the best configuration for a particular application.

Promotion failed:

Garbage collection when the promotion failed is a very headache, the general may be two reasons, the first reason is that the rescue space is not enough, rescue space objects should not be moved to the old generation, but the young generation and many objects need to put into the rescue space The second reason is that the old generation does not have enough space to accommodate the young generation, both of which are turned to full GC, and the site pauses longer.

Solution One:

The first reason my final solution is to remove the rescue space, set the-xx:survivorratio=65536-xx:maxtenuringthreshold=0 can, The second reason my solution is to set Cmsinitiatingoccupancyfraction to a value (assuming 70), so that the old generation of space to 70% when the implementation of the CMS, old generation has enough space to accept from the young generation of objects.

Solution One improvement:

There are improvements, the above method is not very good, because there is no use to save space, so the old generation easily full, CMS execution will be more frequent. I improved a bit, or to save space, but to increase the space to save, so there will not be promotion failed. Specifically, 32-bit Linux and 64-bit Linux do not seem to be the same, the 64-bit system appears to be configured as long as the Maxtenuringthreshold parameter, the CMS still has a pause. In order to solve the suspension problem and promotion failed problem, finally I set up-xx:survivorratio=1, and maxtenuringthreshold removed, so that there is no pause and there will be no promotoin failed, And more importantly, the old generation and the permanent generation rise very slowly (because many objects can not be recycled in the old generation), so the CMS execution frequency is very low, several hours to execute once, so that the server does not have to restart.

-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

The formula of relation between Cmsinitiatingoccupancyfraction value and XMN

The above describes the reason that promontion faild is caused by the lack of Eden space in the Eden and from Survivor in the live object in the to Survivor area, to the survivor area of space, again promoted to the old Gen area, The old Gen area also had insufficient memory to produce the promontion faild which led to the full GC. It can be inferred that promontion faild does not occur when the remaining memory is Eden+from survivor < That
(XMX-XMN) * (1-cmsinitiatingoccupancyfraction/100) >= (xmn-xmn/(survivorratior+2)) and 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 xmn=24 survivorratior=1 cmsinitiatingoccupancyfraction<= ((128.0-24)-(24-24/(1+2)))/(128-24) *100= 84.615 ...

When xmx=3000 xmn=600 survivorratior=1 cmsinitiatingoccupancyfraction<= ((3000.0-600)-(600-600/(1+2)))/(3000-600) * 100=83.33

Cmsinitiatingoccupancyfraction below 70% need to adjust xmn or survivorratior values.

Make:

Online a child's shoes deduced the formula is::(xmx-xmn) * (100-cmsinitiatingoccupancyfraction)/100>=xmn This formula is not very strict, in the memory of small time will affect the calculation of Xmn.

For the GC parameter configuration of the actual environment see: example analysis monitoring tools see JVM Monitoring

Reference:

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

Several important parameters of the JVM (principal)

Java JVM parameter-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 (included test examples are useful)

Tell me about the Maxtenuringthreshold parameter.

Original address: http://www.cnblogs.com/redcreen/archive/2011/05/04/2037057.html

(GO) JVM series three: JVM parameter settings, analysis