Topic:

1. JVM tuning reasons - Why JVM tuning is done! (Hayne's Law, Murphy's Law) 2, JVM tuning principle - garbage collection algorithm, how to tune 3, JVM tuning actual practice -- set JVM tuning parameters, according to these parameters of the pressure test 4, JVM tuning GC log, according to the log situation, the service again tuneCopy the code

1 Why JVM tuning?

Thought 1: After the project went live, what made us need to tune the JVM

1), too much garbage (Java thread, object occupied memory), memory occupied, the program can not run!! 2) Too many garbage collection threads cause frequent garbage collection (garbage collection threads themselves also occupy resources, such as memory and CPU resources), leading to performance degradation of the program. 3) Frequent garbage collection leads to STW

Therefore, for these reasons, the application must be tuned once it is online, otherwise the performance of the application cannot be improved; That is, after the program goes online, a reasonable garbage collection strategy must be set up;

Thought 2: What is the nature of JVM tuning?

Answer: Recycle garbage, recycle unused garbage objects, free up memory space in time

Think 3: How much JVM heap memory should be set based on the server environment?

32-bit OS – addressing capability 2^32 = 4GB, maximum 4GB support; The JVM can allocate 2g+

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

The Jvm heap memory should not be set too large, which will take too long to address garbage, which will cause the entire program to STW, nor too small, which will cause garbage collection too frequently.

2 Jvm tuning Principles

1) The GC time is small enough (the heap memory setting should be small enough)

2), enough gc times (heap memory setting is large enough) —- garbage is full (it takes a long time to fill the space), garbage collection starts

3) The full GC cycle is long enough

1) Metaspace permanent generation space is set slightly reasonable, permanent generation generation expansion, immediately occur full GC 2) old generation set space is larger, if the old generation is not enough, never happen full GC 3) try to let the garbage generation is recycled 4) try to reduce the number of large objectsCopy the code

3 Jvm tuning principles -GC

3.1 What is garbage?

Objects that are not referenced in memory are garbage; In heap memory, if an object reference is lost, the object must be reclaimed;

3.2 How to find garbage?

There are two types of garbage finding algorithms (garbage finding methods) in the Jvm: reference counting algorithm 2 root reachable algorithm 1 reference counting algorithmThe way the reference counting algorithm determines that an object is garbage is that when the count is zero, it determines that the object is garbage; Problems: Cannot solve the problem of circular reference counting;

The above objects refer to each other, so the reference count is never zero, so it is not garbage. However, none of these objects are referenced by external objects, so they are garbage.

2) Root reachable algorithm

The root reachable algorithm is the mainstream garbage collection algorithm used by JVM at present. Oracle hotspot uses this algorithm;

3.3 How Do I Remove Garbage?

The Jvm provides three methods (algorithms) —– 1, Mark-sweep algorithm 2, Copying – copy algorithm 3, and Mark-Compact tag compression algorithm

1) Mark-sweep — mark-sweep algorithm

Advantages: simple and efficient Disadvantages: there are a lot of discontinuous memory space, memory space fragmentation; The efficiency and performance of addressing decrease

1) Copying — copying

Copy the living objects to the other half of the space, which is the continuous memory space. 3. After all the living objects are copied, clear the upper half of the space to complete garbage collection.

Advantages: simple, memory space is continuous, do not worry about memory space fragmentation disadvantages: memory space waste

3) Mark-Compact markup compression algorithm

1, mark garbage, do not remove garbage 2, scan again, and slide to one end (copy) live objects (unmarked objects) 3, recycle garbage in the memory space of the other end

3.4 Available garbage collector

The Java language has a feature that has its own garbage collector; And there are lots of garbage collectors; Therefore, different garbage collectors need to be selected according to different scenarios;

The Jvm provides 10 types of garbage collectors; With so many garbage collectors, which combination of garbage collectors should be used in a project?

1) Serial (young generation garbage collection) + serialOld (old generation garbage collection) serial(young generation garbage collection) + serialOld

2) parNew + CMS: parallel; Concurrent garbage collector; This combination takes precedence over the garbage collector combination in response time

The Parallel Exploiter + Parallel Old is the JDK’s default garbage collector

4) G1 garbage collector (logical generation), combining the young generation and the old generation into one way for garbage collection;

3.5 Serial garbage collector

Note:

1. When garbage collection is performed, all business threads must be suspended for garbage collection to take place;

Safe Point allows user threads to be suspended so that JVM threads can safely mark garbage.

3.6 Ps + po

ParNew + 3.7 CMS

3.8 G1 garbage collector

4 Memory generation model

Question: What does a large object do when it comes? Eden can fit it? — No — (YGC) — Eden can fit? – can ever – old – – can fit into a old whether — — — — — — fullgc oom

5 JVM tuning practices

5.1 Typical Tuning Parameter Settings

Server configuration: 4CPU,8GB of memory —- JVM tuning is actually setting up a reasonable size of JVM heap memory (neither too large nor too small)

-xmx3550m Sets maximum JVM heap memory (empirical setting: According to the pressure test, according to the online program running effect) -xMS3550m set the initial size of JVM heap memory, under normal circumstances must set this value and the maximum maximum heap memory space to keep consistent, to prevent memory jitter. Consumption performance -xmn2G sets the size of the space occupied by the young generation -xSS256K sets the size of the thread stack; The default thread stack size after JDK5.0 is 1MB; With the same amount of memory, reducing the stack size allows the operating system to create more business threads;Copy the code

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 Analyzing GC Logs

If gc logs need to be analyzed, the service GC must enter GC details into the log file and then analyze the logs using the appropriate GC log analysis tool.

Output the GC details to a gc.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)

After analyzing the GC logs, it was found that there were three fullGCs at the beginning, and it was clear that the JVM optimization parameters were set incorrectly.Cause: jstat -gcutil PID

Metaspace persistent generation: The initial allocation size is 20m. When Metaspace is used up, the capacity of the persistent generation must be expanded. If Metaspace is expanded every time, fullGC needs to be expanded once. (FullGC reclaims the entire heap space, which takes a lot of time)

Adjust GC configuration: Modify permanent generation space initialization size:

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 proportion

Ratio of the young generation to the old generation: 1:2 Parameter: -xx :NewRetio = 4, indicating that the ratio between the young generation (Eden, S0, S1) and the old generation is 1:4

1) -xx :NewRetio = 4

The younger generation allocates less memory, so the number of YGC is more, although the fullgc does not happen, but YGC takes more time!

2) -xx :NewRetio = 2 The frequency of YGC will inevitably decrease; Because the Eden region is larger, the YGC will be smaller;

5.4 Eden&S 0 s1

To further reduce YGC, the ratio of enden and S region can be set. Setting mode: -xx :SurvivorRatio=8

1) Set the 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 $&

In terms of GC tuning, garbage collection times, times, throughput is a better configuration;

5.5 Throughput Priority

With a parallel garbage collector, you can take full advantage of multi-core cpus to help with garbage collection; This gc approach is called throughput first tuning

The garbage collector is the Jdk1.8 default garbage collector insane.

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 Priority in response time

With the CMS garbage collector, it’s a response-first combination; The CMS garbage collector (garbage collection and business threads are interspersed, so that business threads do not pause STW) minimizes the STW time as much as possible, so the CMS garbage collector combination is a response-first 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 $&

As you can see, the CMS garbage collector takes longer;

5.7 the g1

The configuration mode 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 $&