In-depth analysis of JVM tuning principles and online service optimization practice

• Reasons for jvm tuning-why jvm tuning! (Hain's Law, Murphy's Law)
• The principle of jvm tuning-garbage collection algorithm, how to tune
• Jvm tuning actual combat-set jvm tuning parameters, and stress test based on these parameters
• Jvm tuning gc log, according to the log situation, re-tune the service

1 Why do JVM tuning?

Thinking 1: After the project went live, what caused us to perform jvm tuning

• Too much garbage (java threads, objects take up memory), the memory is full, and the program can't run! !
• There are too many garbage collection threads, and frequent garbage collection (garbage collection threads themselves also occupy resources: memory, cpu resources), resulting in decreased program performance
• Frequent garbage collection causes STW

Therefore, based on the above reasons, after the program is online, it must be tuned, otherwise the program performance cannot be improved; that is, after the program is online, a reasonable garbage collection strategy must be set;

Thinking 2: What is the essence of jvm tuning? ?

Answer: Recycle garbage, recycle unused garbage objects in time, and release memory space in time

Thinking 3: Based on the server environment, how much memory should be set for jvm heap memory?

• 32-bit operating system-addressing capacity 2^32 = 4GB, the largest can support 4gb; jvm can allocate 2g+

• 64-bit operating system — addressing capability 2^64 = 16384PB, high-performance computer (IBM Z unix 128G 200+)
  

The jvm heap memory cannot be set too large, otherwise it will cause the garbage addressing time to be too long, that is, the STW of the entire program can not be set too small, otherwise it will cause the garbage collection to be too frequent;

Organized some document notes. I also sorted out some interview materials & the latest interview questions collected by some big companies in 2020 (all organized into documents, a small part of the screenshots), if you need it, please click here, here , and the code: CSDN.

Organized some document notes. I also sorted out some interview materials & the latest interview questions collected by some big companies in 2020 (all organized into documents, a small part of the screenshots), if you need it, please click here, here , and the code: CSDN.

2 JVM tuning principles

1. gc time is small enough (heap memory setting should be small enough)
   

2. The number of gc is small enough (heap memory setting is large enough) ---- garbage is full (it takes a long time to fill up the space), then garbage collection starts

3. The occurrence of full gc cycle is long enough
   1) The permanent generation space setting of metaspace is slightly more reasonable, and the permanent generation expansion will cause full gc immediately.
   2) The setting space of the old generation is larger. If the old generation is not full, full gc will never happen
   3) Try to allow garbage to be collected in the younger generation
   4) Try to minimize large objects

3 Principles of JVM Tuning-GC

3.1 What is garbage?

There are no referenced objects in memory, these objects are garbage; in heap memory, an object reference is gone, then this object must be recycled;

3.2 How to find garbage?

There are two kinds of garbage searching algorithms in JVM (the method of finding garbage)

• Reference counting algorithm
• Root reachability algorithm

1) Reference counting algorithm The method for the

reference counting algorithm to judge that an object is garbage is to judge that the object is garbage when the count is 0; There is a problem: the problem of circular reference counting cannot be solved; the

above objects refer to each other, leading to reference counting It is always not 0, so it cannot be judged as garbage, but none of these objects are referenced by external objects, so they are garbage;

2) Root reachability algorithm

Root reachability algorithm is currently the mainstream garbage collection algorithm used by JVM; Oracle hotspot uses this algorithm;

3.3 How to remove garbage?

JVM provides 3 methods (algorithms)

1. Mark-sweep-mark removal algorithm
2. copying-copy
3. mark-compact mark compression algorithm

1) Mark-sweep — Mark sweep algorithm

1. Search for garbage from the memory space and mark the found garbage
2. Clear the marked garbage.

• Advantages: simple and efficient
• Disadvantages: There are many discontinuous memory spaces, and the memory space is fragmented; resulting in reduced addressing efficiency and performance

2) Copying-Copy

1. Select the surviving object
2. Copy the surviving object to the other half of the space, which is continuous memory space
3. After copying all the surviving objects, directly clear the upper half of the space to complete garbage collection ；

Advantages: Simple, the memory space is continuous, no need to worry about fragmentation of the
memory space Disadvantages: Waste of memory space

3) mark-compact mark compression algorithm

1, mark garbage, do not clear garbage
2, scan again, and slide (copy) surviving objects (unmarked objects) to
one end 3. Reclaim garbage in the memory space at the other end

3.4 Available garbage collectors

The Java language has a feature: it has its own garbage collector; and there are many garbage collectors; therefore, you need to choose different garbage collectors according to different scenarios;

JVM provides 10 kinds of garbage collectors; so many garbage collectors Collector, which combination of garbage collector is used in the project? ?

1) serial (young generation garbage collection) + serialOld (recycling garbage in the old generation): serialized collector, so in the current multi-core cpu, it is not suitable, only suitable for single-core cpu garbage collection;

2) parNew + CMS: parallel; concurrent garbage collector; this combination prioritizes the garbage collector combination in response time

3) Parallel Scavenge + Parallel Old (abbreviation: ps+po): concurrent garbage collector, which is the default garbage collector combination of jdk

4) g1 garbage collector (logically generational), which combines the young and old generations into one for garbage collection;

3.5 Serial Garbage Collector

4 Memory generation model

Question: What do you do after a big object comes? Eden can put it down?

— No — (YGC) — eden can put it down? — No---- old can be down----Yes — can be placed in old -----No---- fullgc oom

5 JVM tuning actual combat

Server configuration: 4cpu, 8GB memory ---- jvm tuning is actually to set a reasonable size of jvm heap memory (neither too large nor too small)

-Xmx3550m  设置jvm堆内存最大值  (经验值设置： 根据压力测试，根据线上程序运行效果情况)
-Xms3550m  设置jvm堆内存初始化大小，一般情况下必须设置此值和最大的最大的堆内存空间保持一致，防止内存抖动，消耗性能
-Xmn2g 设置年轻代占用的空间大小
-Xss256k 设置线程堆栈的大小；jdk5.0以后默认线程堆栈大小为1MB; 在相同的内存情况下，减小堆栈大小，可以使得操作系统创建更多的业务线程；

Jvm heap memory settings:

nohup java -Xmx3550m -Xms3550m -Xmn2g -Xss256k -jar jshop-web-1.0-SNAPSHOT.jar --spring.addition-location=application.yaml > jshop.log 2>&1 $&

TPS performance curve:

5.2 Analyze gc log

If you need to analyze the gc log, you must make the service gc enter gc details into the log log file, and then use the corresponding gc log analysis tool to analyze the log;

Output gc details to a gc.log log file for gc analysis

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps
-XX:+PrintHeapAtGC -Xloggc:gc.log

Throughput: business thread execution time / (gc time + business thread time)

analyze the gc log and found that 3 fullgc occurred at the beginning. It is obvious that there is a problem with the setting of jvm optimization parameters;

check the cause of the problem with fullgc: jstat- gcutil pid

Metaspace persistent generation: the
initial allocation size is 20m. When the metaspace is full, the persistent generation must be expanded. If the metaspace is expanded every time, fullgc needs to be executed once; (fullgc reclaims the entire heap space, which takes time)

Adjust gc configuration: Modify the initialization size of permanent generation space:

nohup java -Xmx3550m -Xms3550m -Xmn2g -Xss256k -XX:MetaspaceSize=256m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log -jar jshop-web-1.0-SNAPSHOT.jar --spring.addition-location=application.yaml > jshop.log 2>&1 $&

After tuning, the fullgc phenomenon has disappeared:

5.3 Young&Old ratio

Ratio of young generation to old generation: 1:2 Parameters: -XX:NewRetio = 4, which means that the ratio of young generation (eden, s0, s1) to the old generation is 1:4

1) -XX:NewRetio = 4
The memory size allocated by the young generation has become smaller, so the number of YGCs has increased. Although fullgc does not occur, YGC takes more time!

2) -XX:NewRetio = 2 The number of YGC occurrences will inevitably be reduced; because the size of the eden area becomes larger, the YGC will be reduced;

5.4 Eden&S0S1

In order to further reduce YGC, you can set the ratio of enden and s area; setting method: -XX:SurvivorRatio=8

1) Setting ratio: 8:1:1

2） Xmn2g 8:1:1

nohup java -Xmx3550m -Xms3550m -Xmn2g -XX:SurvivorRatio=8 -Xss256k -XX:MetaspaceSize=256m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log -jar jshop-web-1.0-SNAPSHOT.jar --spring.addition-location=application.yaml > jshop.log 2>&1 $&

According to gc tuning, the number of garbage collections, time, and throughput are all a relatively optimal configuration;

5.5 Throughput priority

Using a parallel garbage collector, you can make full use of multi-core cpu to help garbage collection; such a gc method is called a throughput-first tuning method.
Garbage collector combination: ps (parallel scavenge) + po (parallel old)
this The garbage collector is the default garbage collector combination of Jdk1.8;

nohup java -Xmx3550m -Xms3550m -Xmn2g -XX:SurvivorRatio=8 -Xss256k -XX:+UseParallelGC -XX:UseParallelOldGC -XX:MetaspaceSize=256m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log -jar jshop-web-1.0-SNAPSHOT.jar --spring.addition-location=application.yaml > jshop.log 2>&1 $&

5.6 Response time priority

Using cms garbage collector is a combination of response time priority; cms garbage collector (garbage collection and business thread cross execution, will not let the business thread to stall the stw) as much as possible to reduce the time of stw, so use the cms garbage collector Combination, is the response time priority combination

nohup java -Xmx3550m -Xms3550m -Xmn2g -XX:SurvivorRatio=8 -Xss256k -XX:+UseParNewGC -XX:UseConcMarkSweepGC -XX:MetaspaceSize=256m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log -jar jshop-web-1.0-SNAPSHOT.jar --spring.addition-location=application.yaml > jshop.log 2>&1 $&

It can be found that the cms garbage collector time becomes longer;

5.7 g1

The configuration method is as follows:

nohup java -Xmx3550m -Xms3550m -Xmn2g -XX:SurvivorRatio=8 -Xss256k -XX:+UseG1GC -XX:MetaspaceSize=256m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log -jar jshop-web-1.0-SNAPSHOT.jar --spring.addition-location=application.yaml > jshop.log 2>&1 $&

Pay attention, don't get lost! If this article is helpful to you, don't forget to like and support!