1. Introduction to JVM Tuning Parameters
1. Introduction to JVM parameters
The -XX parameters are called unstable parameters because the settings of such parameters can easily cause differences in JVM performance and make the JVM extremely unstable. If such parameters are set reasonably, the performance and stability of the JVM will be greatly improved.
Unstable parameter syntax rules:
1. Boolean type parameter value-XX:+<option> '+' means enable the option
-XX:-<option> '-' means close this option
2. Numeric type parameter value:
-XX:<option>=<number > Give the option a numeric value, followed by a unit, for example: 'm' or 'M' for megabytes; 'k' or 'K' for kilobytes; 'g' or 'G' for gigabytes. 32K is the same size as 32768.
3. String type parameter value:
-XX:<option>=<string> Set a string type value for the option, usually used to specify a file, path or a series of command list.
For example: -XX:HeapDumpPath=./dump.core
2. Example of JVM parameters
配置： -Xmx4g –Xms4g –Xmn1200m –Xss512k -XX:NewRatio=4 -XX:SurvivorRatio=8 -XX:PermSize=100m
-XX:MaxPermSize=256m -XX:MaxTenuringThreshold=15
Resolution:-Xmx4g: The maximum heap memory is 4GB.
-Xms4g: Initialize heap memory size to 4GB.
-Xmn1200m: Set the young generation size to 1200MB. When the young generation is increased, the old generation size is reduced. This value has a great impact on system performance, and Sun officially recommends setting it to 3/8 of the entire heap.
-Xss512k: Set the stack size per thread. After JDK5.0, the stack size of each thread is 1MB, and the stack size of each thread was 256K before. It should be adjusted according to the amount of memory required by the application threads. In 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, and the experience value is around 3000~5000.
-XX:NewRatio=4: Set the ratio of young generation (including Eden and two Survivor areas) to old generation (excluding persistent generation). If it is set to 4, 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.
-XX:SurvivorRatio=8: Set the size ratio of the Eden area to the Survivor area in the young generation. If it is set to 8, 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:PermSize=100m: Initialize the permanent generation size to 100MB.
-XX:MaxPermSize=256m: Set the persistent generation size to 256MB.
-XX:MaxTenuringThreshold=15: Set the maximum age of garbage. If it is set to 0, the young generation objects directly enter the old generation without passing through the Survivor area. For applications with a large number of old generations, the efficiency can be improved. If this value is set to a larger value, the young generation objects will be replicated multiple times in the Survivor area, which can increase the survival time of the objects in the young generation and increase the generalization that they will be recycled in the young generation.
2. JVM tuning goals
1. When should jvm tuning be done?1. The heap memory (old age) continues to rise and reaches the set maximum memory value;
2. The number of Full GC is frequent;
3. The GC pause time is too long (more than 1 second); 4. The application
has memory exceptions such as OutOfMemory;
Use local cache and take up a lot of memory space;
6. System throughput and response performance are low or degraded.
2. JVM tuning principles
1. Most Java applications do not require JVM optimization on the server;
2. Most of the Java applications that cause GC problems are not because of wrong parameter settings, but code problems;
3. Before the application goes online, consider setting the JVM parameters of the machine to the optimal (most suitable);
4. Reduce the number of objects created;
5. Reduce the use of global variables and large objects;
6. JVM optimization is a last resort;
7. In actual use, it is better to analyze the GC situation to optimize the code than to optimize the JVM parameters;
3. JVM tuning goals
1. GC low pause;
2. GC low frequency;
3. Low memory usage;
4. High throughput;
JVM tuning quantification goals (example):
1. Heap memory usage <= 70%;
2. Old generation memory usage <= 70%;
3. avgpause <= 1 second;
4. Full gc times 0 or avg pause interval >= 24 hours;
Note: Different applications have different JVM tuning quantification goals.
3. JVM tuning experience
1. Summary of JVM tuning experience
The general steps for JVM tuning are:
Step 1: Analyze GC logs and dump files, determine whether optimization is needed, and identify bottleneck problems;
Step 2: Determine the JVM tuning quantification target;
Step 3: Determine JVM tuning parameters (adjusted according to historical JVM parameters);
Step 4: Tuning a server, compare and observe the difference before and after tuning;
Step 5: Continuous analysis and adjustment until a suitable JVM parameter configuration is found;
Step 6: Find the most suitable parameters, apply them to all servers, and follow up.
2. Analysis of important parameters for JVM tuning
Note: Different applications have different JVM optimal stable parameter configurations.
Configuration: -server
-Xms12g -Xmx12g -XX:PermSize=500m -XX:MaxPermSize=1000m -Xmn2400m -XX:SurvivorRatio=1 -Xss512k -XX:MaxDirectMemorySize=1G
-XX:+DisableExplicitGC -XX:CompileThreshold=8000 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
-XX:+UseCompressedOops -XX:CMSInitiatingOccupancyFraction=60 -XX:ConcGCThreads=4
-XX:MaxTenuringThreshold=10 -XX:ParallelGCThreads=8
-XX:+ParallelRefProcEnabled -XX:+CMSClassUnloadingEnabled -XX:+CMSParallelRemarkEnabled
-XX:CMSMaxAbortablePrecleanTime=500 -XX:CMSFullGCsBeforeCompaction=4
XX:+UseCMSInitiatingOccupancyOnly -XX:+UseCMSCompactAtFullCollection
-XX:+HeapDumpOnOutOfMemoryError -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/weblogic/gc/gc_$$.log
Analysis of important parameters (tunable):
-Xms12g: Initialize heap memory size to 12GB.
-Xmx12g: Maximum heap memory is 12GB.
-Xmn2400m: The size of the new generation is 2400MB, including the Eden area and 2 Survivor areas.
-XX:SurvivorRatio=1: The ratio of the Eden area to a Survivor area is 1:1.
-XX:MaxDirectMemorySize=1G: Direct memory. This value can be increased by reporting java.lang.OutOfMemoryError: Direct buffer memory exception.
-XX:+DisableExplicitGC: Disable explicit calls to System.gc() at runtime to trigger full GC.
Note: The timing GC trigger mechanism of Java RMI can control the trigger time by configuring -Dsun.rmi.dgc.server.gcInterval=86400.
-XX:CMSInitiatingOccupancyFraction=60: The old generation memory recovery threshold, the default value is 68.
-XX:ConcGCThreads=4: CMS garbage collector parallel thread lines, the recommended value is the number of CPU cores.
-XX:ParallelGCThreads=8: The number of threads of the new generation parallel collector.
-XX:MaxTenuringThreshold=10: Set the maximum age of garbage. If it is set to 0, the young generation objects directly enter the old generation without passing through the Survivor area. For applications with a large number of old generations, the efficiency can be improved. If this value is set to a larger value, the young generation objects will be replicated multiple times in the Survivor area, which can increase the survival time of the objects in the young generation and increase the generalization that they will be recycled in the young generation.
-XX:CMSFullGCsBeforeCompaction=4: After specifying how many times fullGC is performed, the memory space in the tenured area is compressed.
-XX:CMSMaxAbortablePrecleanTime=500: When the execution of the abortable-preclean preclean phase reaches this time, it will end.
3. Scenarios that trigger Full GC and countermeasures
The young generation space (including the Eden and Survivor areas) reclaims memory is called Minor GC, and the old generation GC is called MajorGC, while Full GC is for the entire heap. In recent versions of JDK, the default includes immortality. With the recovery of the method area (there is no immortal belt in JDK8), when a Full GC occurs, it is often accompanied by at least one Minor GC, but it is not absolute. The speed of MajorGC is generally more than 10 times slower than that of Minor GC.
Scenarios and countermeasures for triggering Full GC:
1. System.gc() method call, coping strategy: prohibit calling System.gc through -XX:+DisableExplicitGC;
2. Insufficient space in the old generation, coping strategy: let the object be recycled in the Minor GC stage, let the object survive for a while in the new generation, do not create too large objects and arrays;
3. Insufficient space in the immortal area, coping strategy: increase the PermGen space
4. Promotionfailed and concurrent mode failure occur during GC, coping strategy: increase survivor space
5. The size of the object promoted to the old generation after Minor GC is larger than the remaining space of the old generation. Coping strategy: increase Tenured space or decrease CMSInitiatingOccupancyFraction=60
6. The memory continues to increase and reaches the upper limit, resulting in Full GC. Coping strategy: analyze whether there is a memory leak through dumpheap
4. Gc log analysis tool
With the help of the GCViewer log analysis tool, the advantages to be adjusted can be analyzed very intuitively.
It can be analyzed from the following aspects:
1.Memory, analyze the memory usage of Totalheap, Tenuredheap, Youngheap and other indicators. In theory, the smaller the memory usage, the better;
2.Pause, analyze the indicators in the three major items of Gc pause, Fullgc pause, and Total pause. In theory, the fewer GC times, the better, and the shorter the GC duration, the better;
5. MAT heap memory analysis tool
EclipseMemory Analysis Tools (MAT) is a professional tool for analyzing Java heap data to locate the cause of memory leaks.
Refer to the following links:
https://blog.csdn.net/u011683530/article/details/51013219
https://www.cnblogs.com/God-froest/p/jvm_1_3.html