JVM parameter Tuning __JVM

Whether the YGC or full GC,GC process will cause interruption in the operation of the program, the correct choice of different GC policies, adjust the JVM, GC parameters, can greatly reduce the GC work, resulting in the interruption of program operation, and then appropriate to improve the efficiency of the Java program. But tuning the GC is a very complex process, because of the different characteristics of each program, such as: Web and GUI programs have a big difference (the Web can be a proper pause, but the GUI pauses are unacceptable to customers), and because of the different configurations running on each machine (the number of main Cup, different memory), So the types of GC you use are different (how to choose the GC and how to choose). This article will focus on the JVM, GC some important parameters of the settings to improve system performance.

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

Examples of the implications of JVM parameters: a case study

Implications of JVM parameters (case analysis)
Parameter name	meaning	Default Value	Explain in detail
-xms	Initial Heap Size	1/64 of physical memory (<1GB)	Default (Minheapfreeratio parameters can be adjusted) when the free heap memory is less than 40%, the JVM increases the maximum limit of the heap until-xmx.
-xmx	Maximum Heap Size	1/4 of physical memory (<1GB)	Default (Maxheapfreeratio parameters can be adjusted) when the free heap memory is greater than 70%, the JVM reduces the heap until the minimum limit of-XMS
-xx:permsize	Set persistent generation (perm Gen) initial value	1/64 of physical memory	Set non-heap memory initial value
-xx:maxpermsize	To set the maximum value for a persistent generation	1/4 of physical memory	To set the maximum non-heap memory size
-xmn	Young generation size (1.4 or later)	3/8 of the whole heap	Note: The size here (Eden + 2 survivor space) is different from the new Gen shown in Jmap-heap. Entire Heap size = young generation size + old age size + persistent generation size. Increasing the number of young generations will reduce the size of the older generation, which has a greater impact on system performance, Sun officially recommended configuration for the entire heap of 3/8
-xx:newsize	Set young generation size (for 1.3/1.4)		Set Young generation size
-xx:maxnewsize	Set the young generation maximum (for 1.3/1.4)		Set maximum young generation size
-xss	stack size for each thread		After JDK5.0, each thread stack size is 1M, and the previous thread stack size is 256K, adjusted according to the memory size required by the application thread. Under the same physical memory, reducing this value can generate more threads. But the operating system on a process of the number of threads is still limited, can not be unlimited generation, experience in the 3000~5000 or so, the general small application, if the stack is not very deep, should be 128k sufficient, large application recommended 256k. This option has a higher performance impact and requires rigorous testing. Similar to the Threadstacksize option explanation, the official document does not seem to explain, in the forum there is a sentence: "-XSS is translated in a VM flag named Threadstacksize", general set this value on it.
-xx:threadstacksize	Thread Stack Size		(0 means use default stack size) [sparc:512; Solaris x86:320 (is 256 prior in 5.0 and earlier); Sparc bit:1024; Linux amd64:1024 (is 0 in 5.0 and earlier); All others 0.]
-xx:newratio	Ratio of young generation (including Eden and two survivor districts) to older generation (excluding persistent generation)		-xx:newratio=4 that the ratio of the younger generation to the older generation was 1:4, and that the young generation accounted for 1/5 of the entire stack. Xms=xmx and the xmn is set, this parameter does not need to be set.
-xx:survivorratio	Ratio of the size of the Eden area to the survivor area (Young generation internal)		Set to 8, the ratio of two survivor to an Eden area was 2:8, and a survivor area accounted for 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 rubbish		If set to 0, then the younger generation of objects do not go through the survivor area directly into the old generation. More applications for older generations can improve efficiency. If this value is set to a larger value, the young generation object will replicate multiple times in the Survivor area, which can increase the lifetime of the object's younger generation and increase the probability of being recycled in the younger generation, which is valid only for serial GC.
-xx:+aggressiveopts	Faster compilation
-xx:+usebiasedlocking	Performance improvement of lock mechanism
-xnoclassgc	disabling garbage collection
-xx:softreflrupolicymspermb	Survival time of SoftReference in the free space of each mega-heap	1s	Softly reachable objects'll remain alive for some amount of the "after" the last time they were. The default value is one second of lifetime/free megabyte in the heap
-xx:pretenuresizethreshold	Objects over how large are directly distributed in the old generation	0	The unit byte is not valid when the Cenozoic adopts parallel scavenge GC Another case that is directly assigned to the old generation is a large array object, and there are no external reference objects in the array.
-xx:tlabwastetargetpercent	Tlab Percentage of Eden area	1%
-xx:+collectgen0first	Whether to YGC first when FULLGC	False

 

If this time cannot be met

td>

parallel Collector related parameters
Parameter name	meaning	Default Value	Explain in detail
-xx:+useparallelgc	Full GC with parallel MSC (This item is to be validated)		Select the garbage collector as the parallel collector. This configuration is only valid for young generations. That is, the younger generation uses concurrent collections, while older generations still use serial collections. (This item is to be validated)
-xx:+useparnewgc	Set up young to collect parallel		Can be used concurrently with CMS collection, JDK5.0 the JVM will set itself according to the system configuration, so no more setting this value
-xx:parallelgcthreads	Number of threads in parallel collector		This value is best configured to be equal to the number of processors, also applicable to 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 per young generation of garbage collection (max. Timeout)