JVM Series 3: JVM parameter settings and Analysis

Whether it is ygc or full GCProgramDuring running interruption, correctly select different GC policies and adjust JVM and GC parameters, which can greatly reduce the program running interruption caused by GC, in this way, the Java program's work efficiency can be appropriately improved. However, adjusting GC is a very complex process. Because each program has different characteristics, for example, the web and GUI programs are very different (the Web can be properly paused, however, the user cannot accept the GUI pause, and because the configurations running on each machine are different (the number of major CPUs and memory are different ), the GC types used are also different (for how to select the Gc Types and how to select them ). This article focuses on setting important JVM and GC parameters to improve system performance.

For details about JVM memory composition and GC, see the previousArticle: JVM memory composition GC Policy & memory application.

JVM parameter descriptionSee instance analysis for instances.

Parameter Name	Description	Default Value
-XMS	Initial heap size	1/64 of physical memory (<1 GB)	By default (the minheapfreeratio parameter can be adjusted) when the free heap memory is smaller than 40%, the JVM will increase the heap until the maximum limit of-xmx.
-Xmx	Max heap size	1/4 of physical memory (<1 GB)	By default (the maxheapfreeratio parameter can be adjusted) when the free heap memory is greater than 70%, the JVM will reduce the minimum heap limit until-XMS
-Xmn	Young Generation size (1.4or lator)		Note:: The size here is (EDEN + 2 kernel vor space). It is different from the new gen shown in jmap-heap. Total heap size = size of the young generation + size of the old generation + size of the persistent generation. After the young generation is increased, the size of the old generation will be reduced. This value has a great impact on system performance. Sun officially recommends setting it to 3/8 of the total heap.
-XX: newsize	Set the young generation size (for 1.3/1.4)
-XX: maxnewsize	Maximum young generation (for 1.3/1.4)
-XX: permsize	Set the initial value of perm gen	1/64 of physical memory
-XX: maxpermsize	Set the maximum value of permanent generation	1/4 of physical memory
-XSS	Stack size of each thread		After JDK, the stack size of each thread is 1 MB, and the previous stack size of each thread is K. the memory size required for more application threads is adjusted. reduce this value to generate more threads in the same physical memory. however, the operating system still has a limit on the number of threads in a process. It cannot be generated infinitely. The experience is between 3000 and ~ Around 5000 million For small applications, if the stack is not very deep, 256 k is recommended for large applications with kb. This option has a big impact on performance and requires rigorous testing. (Principal) Similar to the threadstacksize option, the official document does not seem to be explained. in the Forum, there is a saying :"" -XSS is translated in a VM flag named threadstacksize" You can set this value.
-XX: threadstacksize	Thread stack size		(0 means use default stack size) [iSCSI: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); iSCSI 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.]
-XX: newratio	Ratio of the young generation (including Eden and the two primary vor regions) to the old generation (excluding the permanent generation)		-XX: newratio = 4 indicates that the ratio of the young generation to the old generation is, and the young generation accounts for 1/5 of the entire stack. When XMS = xmx and xmn is set, this parameter does not need to be set.
-XX: Invalid vorratio	Ratio of Eden to vor		If the value is set to 8, the ratio of two vor zones to One Eden zone is. One vor zone occupies 1/10 of the total number of young generations.
-XX: largepagesizeinbytes	The memory page size cannot be too large, which will affect the perm size.		= 128 m
-XX: + usefastaccessormethods	Rapid Optimization of original types
-XX: + disableexplicitgc	Disable system. GC ()		This parameter must be strictly tested.
-XX: maxtenuringthreshold	Maximum age of Spam		If it is set to 0, the young generation object directly enters the old generation without going through the VOR area. for applications with many older generations, the efficiency can be improved. if this value is set to a greater value, the young generation object will be copied multiple times in the same vor area, which can increase the survival time of the young generation object, increase the probability of being recycled in the young generation This parameter is valid only for serial GC.
-XX: + aggressiveopts	Accelerate Compilation
-XX: + usebiasedlocking	Lock Mechanism Performance Improvement
-Xnoclassgc	Disable garbage collection
-XX: softreflrupolicymspermb	Softreference survival time in free space of each MB of heap	1 s	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	If the object size exceeds the upper limit, it is directly allocated in the old generation.	0	The Unit byte generation is invalid when parallel scavenge GC is used. Another case where the old generation is directly allocated is a large array object, and there is no external reference object in the array.
-XX: tlabwastetargetpercent	Percentage of tlab in Eden Zone	1%
-XX: +Collectgen0first	Whether to enable ygc before fullgc	False

Parallel collector Parameters

-XX: + useparallelgc	Full GC adopts parallel MSC (To be verified)		Select the garbage collector as the parallel collector. This configuration is only valid for the young generation. In the preceding configuration, the young generation uses concurrent collection, and the old generation uses serial collection. (This item is to be verified)
-XX: + useparnewgc	Set Young Generation for parallel collection		Can be used together with CMS collection Jdk5.0 or above, JVM will be set based on the system configuration, so no need to set this value
-XX: parallelgcthreads	Number of parallel collector threads		It is best to set this value to be equal to the number of processors for the same CMS
-XX: + useparalleloldgc	Parallel Compacting)		This is a parameter option that appears in Java 6.
-XX: maxgcpausemillis	Maximum time for garbage collection by young generation (maximum suspension time)		If this time cannot be met, JVM will automatically adjust the size of the young generation to meet this value.
-XX: + useadaptivesizepolicy	Automatically select the size of the young generation zone and the ratio of the corresponding region vor Zone		After this option is set, the parallel collector automatically selects the young generation area size and the corresponding proportion of the VOR area to achieve the minimum corresponding time or collection frequency specified by the target system, it is recommended that the parallel Collector be enabled all the time.
-XX: gctimeratio	Set the percentage of garbage collection time to program running 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 Parameters

-XX: + useconcmarksweepgc	Use CMS Memory for collection		After this is configured in the test, the configuration of-XX: newratio = 4 is invalid because it is unknown. Therefore, it is best to set the size of the young generation with-xmn .???
-XX: + aggressiveheap			Trying to use a large amount of physical memory Optimization of large memory usage for a long period of time, check the computing resources (memory, number of processors) Requires at least MB of memory A large amount of CPU/memory (the 1.4.1 CPU has been increased on a 4-CPU machine)
-XX: cmsfullgcsbeforecompaction	How many times after memory Compression		Because the concurrent collector does not compress and tidy up the memory space, "fragments" are generated after running for a period of time, reducing the running efficiency. this value sets the number of GC operations to compress and sort out the memory space.
-XX: + cmsparallelremarkenabled	Lower mark pause
-Xx + usecmscompactatfullcollection	Compression of the old generation during full GC		CMS will not move the memory. Therefore, it is very easy to generate fragments, resulting in insufficient memory usage. Therefore, memory compression will be enabled at this time. Adding this parameter is a good habit. Performance may be affected, but fragments can be eliminated.
-XX: + usecmsinitiatingoccupancyonly	Start CMS collection using manual definition initialization Definition		Prohibit hostspot from triggering cms gc on its own
-XX: cmsinitiatingoccupancyfraction = 70	Use CMS for garbage collection Start CMS collection after using 70%	92	To ensure that the promotion failed (see the following section) error does not occur, the setting of this value must meet the following formula:Cmsinitiatingoccupancyfraction Calculation Formula
-XX: cmsinitiatingpermoccupancyfraction	Set the ratio to which perm gen is triggered	92
-XX: + cmsincrementalmode	Set to incremental Mode		Used for single CPU usage
-XX: + cmsclassunloadingenabled

Auxiliary Information

-XX: + printgc			Output Format: [GC 118250 K-> 113543 K (130112 K), 0.0094143 secs] [Full GC 121376 K-> 10414 K (130112 K), 0.0650971 secs]
-XX: + printgcdetails			Output Format: [GC [defnew: 8614 K-> 781 K (9088 K), 0.0123035 secs] 118250 K-> 113543 K (130112 K), 0.0124633 secs] [GC [defnew: 8614 K-> 8614 K (9088 K), 0.0000665 secs] [tenured: 112761 K-> 10414 K (121024 K ), 0.0433488 secs] 121376 K-> 10414 K (130112 K), 0.0436268 secs]
-XX: + printgctimestamps
-XX: + printgc: printgctimestamps			It can be used together with-XX: + printgc-XX: + printgcdetails Output Format: 11.851: [GC 98328 K-> 93620 K (130112 K), 0.0082960 secs]
-XX: + printgcapplicationstoppedtime	Print the pause time of the program during garbage collection. It can be used together with the above		Output Format: total time for which application threads were stopped: 0.0468229 seconds
-XX: + printgcapplicationconcurrenttime	Print the execution time of the program before each garbage collection. It can be used together with the above		Output Format: application time: 0.5291524 seconds
-XX: + printheapatgc	Print detailed stack information before and after GC
-Xloggc: Filename	Record relevant log information to the file for analysis. Use with the above
-XX: + printclasshistogram	Garbage collects before printing the histogram.
-XX: + printtlab	View tlab space usage
XX: + printtenuringdistribution	View the threshold value of the new life cycle after each minor GC		Desired primary vor size 1048576 bytes, new threshold 7 (max 15) New Threshold 7 indicates that the threshold of the new lifecycle is 7.

GC performance considerations

There are two main indicators for GC performance: throughput (the working time is not counted as the total time proportion of GC time) and pause (when GC occurs, the app cannot respond externally ).

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, the app on the server has the following rules:

• Allocate as many memory as possible to the VM;
• Set XMS and xmx to the same value. If the memory used for Virtual Machine startup is relatively small and many objects need to be initialized at this time, the virtual machine must repeatedly increase the memory.
• The number of processor cores increases, and the memory size increases.

2. The young generation

Another factor affecting app fluency is the size of young generation. The larger the young generation, the less minor collection; but with fixed heap size, the larger young generation means a small tenured generation, this means more major collections (major collection will lead to minor collection ).

Newratio reflects the ratio of young to tenured generation. Newsize and maxnewsize reflect the lower limit and upper limit of young generation. setting these two values to the same value will fix the size of young generation (same as that of XMS and xmx ).

If you want to optimize the volume vorratio, you can also optimize the volume vor size, but this does not have a great impact on performance. Survivorratio is the ratio of Eden to memory or.

Generally, the app on the server has 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 young generation size means reducing the tenured generation size. Make tenured generation large enough to accommodate all live data at any time (leave 10%-20% free ).

Experience & rules

2. Young Generation Size Selection
   • Applications with priority over Response Time: set as large as possible until it is close to the minimum response time limit of the system (based on the actual situation ). in this case, the collection frequency of the young generation is also the smallest. at the same time, reduce the number of objects that reach the old generation.
   • Throughput-first applications: as large as possible, it may reach the Gbit level. Because there is no requirement on the 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 for an hour, it will lead to: 1. The ygc frequency is more frequent. 2. The ygc object may directly enter the old generation. If the old generation is full, FGC will be triggered.
4. Old Generation Size Selection
   1. Response time-first application: The concurrency collector is used in the old generation. Therefore, you need to set the response time carefully. Generally, you need to consider the concurrency session rate and session duration parameters. if the heap setting is small, it may cause memory fragmentation, high recovery frequency, and application suspension. The traditional mark clearing method is used. If the heap is large, it takes a long time to collect. for the optimal solution, you generally need to obtain the following data:
      Concurrent garbage collection information, persistent generation concurrent collection times, traditional GC information, and the proportion of time spent on collection of young and old generations.
   2. Throughput-first applications: Generally, throughput-first applications have a large young generation and a small old generation. the reason is that most of the short-term objects can be recycled as much as possible to reduce the medium-term objects, while the old generation will store the long-term surviving objects as much as possible.
6. Fragmentation problem caused by a small heap
   Because the concurrent collector of the old generation uses the tag to clearAlgorithmSo it does not compress the heap. when the collector recycles the object, it merges the adjacent space and assigns it to a large object. however, when the heap space is small and runs for a period of time, "fragments" will appear. If the concurrent collector cannot find enough space, the concurrent collector will stop, then, we use the traditional mark and clear method to recycle it. if "fragment" appears, you may need to configure it as follows:
   -XX: + usecmscompactatfullcollection: Enable compression for the old generation when the concurrent collector is used.
   -XX: cmsfullgcsbeforecompaction = 0: When the preceding configuration is enabled, how many full GC times are set here to compress the old generation?
8. With a 64-bit operating system, the 64-bit JDK in Linux is slower than the 32-bit JDK, But it consumes more memory and has a higher throughput.
10. The xmx and XMS settings are as large as the maxpermsize and minpermsize settings, which reduces the pressure on the size of the scaling heap.
12. The advantage of using CMS is that the new generation consumes a small amount of data, and the experience is 128 M-256 M. Then the old generation uses CMS for parallel collection, which ensures the system's low-latency throughput efficiency. In fact, the CMS collection pause time is very short, 2 GB memory, about 20-80 ms of application pause time
14. When the system pauses, it may be a GC problem or a program problem. You can use jmap and jstack to view the issue or killall-3 java. Then, you can view the Java console logs to see many problems. (The usage of related tools will be described in the blog below)
16. Carefully understand your applications. If cache is used, the old generation should be larger, and the cached hashmap should not be unlimited. We recommend that you use the LRU algorithm map for caching, the maximum lrumap length must be set according to the actual situation.
18. When concurrent recovery is adopted, the young generation is a little smaller and the old generation is large. Because the old generation uses concurrent recovery, even if the long period of time does not affect other programs to continue running, the website will not pause.
20. There is no fixed formula for setting JVM parameters (especially-xmx-XMS-xmn-XX: survivorratio-XX: maxtenuringthreshold and other parameters, it must be measured based on the actual number of ygc data in the PV old area. To avoid the possibility that promotion faild may lead to a small xmn setting, it also means that the number of ygc times increases and the ability to process concurrent access decreases. Each parameter adjustment must undergo detailed performance tests to find the optimal configuration for a specific application.

Promotion failed:

Promotion failed is a headache During garbage collection, which may be caused by two reasons. The first reason is that the rescue space is insufficient, objects in the rescue space should not be moved to the old generation, but many objects in the young generation need to be put into the rescue space; the second reason is that the old generation does not have enough space to accept objects 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 is that my final solution is to remove the rescue space and set-XX: Export vorratio = 65536-XX: maxtenuringthreshold = 0, the second reason is my solution is to set cmsinitiatingoccupancyfraction to a value (assuming 70) so that CMS will be executed when the old generation space reaches 70%, the old generation has enough space to accept objects from the young generation.

Solution 1:

The above method is not very good, because the rescue space is not used, so the old generation is easy to full, CMS will be executed more frequently. I improved it by using the rescue space, but increased the rescue space, so there would be no promotion failed. In specific operations, 32-bit Linux and 64-bit Linux seem to be different. 64-bit systems seem to be suspended as long as the maxtenuringthreshold parameter is configured. In order to solve the pause and promotion failed problems, I finally set-XX: Always vorratio = 1 and remove maxtenuringthreshold. In this way, no promotoin failed will be available, and more importantly, the rise of the old and permanent generations is very slow (because many objects cannot be recycled in the old generation), so the execution frequency of CMS is very low, and it takes several hours to execute it, the server does not need to be restarted.

-Xmx4000m-xms4000m-xmn600m-XX: permsize = 500 m-XX: maxpermsize = 500 m-xss256k-XX: + disableexplicitgc-XX: Required vorratio = 1-XX: + useconcmarksweepgc-XX: + useparnewgc-XX: + cmsparallelremarkenabled-XX: + usecmscompactatfullcollection-XX: bytes = 0-XX: + cmsclassunloadingenabled-XX: bytes = 128 M-XX: + usefastaccessormethods-XX: + bytes-XX: bytes = 80-XX: softreflrupolicymspermb = 0-XX: + printclasshistogram-XX: + printgcdetails-XX: + printgctimestamps-XX: + printheapatgc-xloggc: log/GC. log

Relationship between cmsinitiatingoccupancyfraction and xmn

The reason for the promontion faild is that when the Eden space is insufficient and the surviving objects in the Eden and from login vor are stored in the to login vor area, the space in the to login vor area is insufficient, again promoted to the Old Gen area, and the old Gen Area Memory is insufficient, resulting in a promontion faild, resulting in full GC. it can be inferred that the promontion faild will not occur when the remaining memory in the Eden + from nation vor <Old Gen zone is used, that is:
(Xmx-xmn) * (1-cmsinitiatingoccupancyfraction/100)> = (xmn-xmn/(using vorratior + 2), then we can 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 export vorratior = 1, cmsinitiatingoccupancyfraction <= (3000.0-600)-(600-600/(1 + 2)/(3000-600) * 100 = 83.33

Cmsinitiatingoccupancyfraction is lower than 70%. You need to adjust the xmn or strongvorratior value.

Order:

The formula inferred from the online shoes is: (xmx-xmn) * (100-cmsinitiatingoccupancyfraction)/100> = xmn. I personally think it is not very rigorous, when the memory size is small, the calculation of xmn is affected.

For more information about GC parameter configuration in the actual environment, see instance analysis and monitoring tools. For details, see JVM monitoring.

Refer:

Java hotspot VM (http://www.helloying.com/blog/archives/164)

Several important JVM parameters (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 (the test example is useful)

Maxtenuringthreshold

 

Recommended articles:

GC optimization method summary

Java 6 JVM Parameter options (Chinese Version)