JVM-tuning tool detailed explanation and tuning actual combat

Tuning tools

jps

• View the process of running java

jmap

jmap -histo 30340  #查看历史生成的实例
jmap -histo:live 30340  #查看当前存活的实例，执行过程中可能会触发一次full gc

• num: serial number
• instances: number of instances
• bytes: size of occupied space
• class name：类名称，[C is a char[]，[S is a short[]，[I is a int[]，[B is a byte[]，[[I is a int[][]

jmap -dump:format=b,file=/Users/mac/Desktop/java学习/Dump/2.hprof 31274

• Put the created dump file into the /Users/mac/Desktop/java learning/Dump folder.
• The generated dump file can be parsed by perfma to view some memory information.
  

jstack

• Use jstack to view thread deadlock problem

jstack -pid

"Thread-1" thread name
prio=5 priority=5
tid=0x000000001fa9e000 thread id
nid=0x2d64 thread corresponding to the local thread ID nid
java.lang.Thread.State: BLOCKED thread state

• It can be seen that Thread-1 is waiting for Thread-0's lock, Thread-0 is waiting for Thread-1's lock, so it deadlocks .

View the most frequently used code of cpu

• Use the top command to find the most frequently used threads
• Use jstack to find the corresponding code by thread id

jinfo

• View jvm parameters

jinfo -flags <pid># 查找出所有的参数

jstat

jstat -gc pid 1000 10# 评估gc 压力 每1秒输出，一共输出10次

• S0C: The size of the first survival area, in KB
• S1C: The size of the second survival area
• S0U: The used size of the first survival area
• S1U: The used size of the second survival area
• EC: The size of Eden Park
• EU: Use size of Eden Park
• OC: Old age size
• OU: size used in the old age
• MC: Method area size (meta space)
• MU: Method area used size
• CCSC: Compressed class space size
• CCSU: compressed class space usage size
• YGC: Number of young generation garbage collections
• YGCT: the time consumed by young generation garbage collection, in s
• FGC: Number of garbage collections in the old age
• FGCT: the time consumed by garbage collection in the old age, in s
• GCT: Total time consumed by garbage collection, in s

You can also use the parameter **-Xloggc:/Users/mac/Desktop/java learning/GC/gc-%t.log**

• Enter the file into /Users/mac/Desktop/java learning/GC/gc-%t.log and use the tool gceasy to analyze the gc file
  

JVM operation estimation

Growth rate of young objects

• You can execute the command jstat -gc pid 1000 10 (execute the command once every 1 second, a total of 10 times), by observing the EU (the use of eden area) to estimate how many objects are added to eden per second , if the system load is not high , You can change the frequency from 1 second to 1 minute or even 10 minutes to observe the overall situation. Note that the general system may have a peak period and a daily period, so it is necessary to estimate the growth rate of the object under different conditions at different times.

Young GC trigger frequency and time-consuming each time

• Knowing the growth rate of objects in the young generation, we can infer how often Young GC is triggered based on the size of the eden zone. The average time of Young GC can be calculated by the YGCT/YGC formula. Based on the results, we can probably know how long the system will be due to How long is the execution of Young GC stuck?

How many objects survive each Young GC and enter the old age

• This is because the frequency of Young GC has probably been known before. If it is every 5 minutes, then you can execute the command jstat -gc pid 300000 10 to observe the changes in eden, survivor and old age usage. After each gc, eden The area usage will generally be greatly reduced. Survivor and the old age may grow. These increased objects are the objects that survive each Young GC. At the same time, you can see how many objects go into the old age after each Young GC, so you can calculate The growth rate of objects in the old age.

Full GC trigger frequency and time-consuming each time

• Knowing the growth rate of objects in the old age can calculate the trigger frequency of Full GC. Each time it takes for Full GC can be calculated using the formula FGCT/FGC.

In fact, the optimization idea is simply to try to make the surviving objects less than 50% of the Survivor area after each Young GC remain in the young generation. Try not to let the subject enter the old age. Try to reduce the frequency of Full GC to avoid the impact of frequent Full GC on JVM performance.

Arthas documentation

• Go to the folder where you downloaded Arthas and run ./as.sh
• Command: dashboard
  Input dashboard to view the running status of the entire process, thread, memory, GC, operating environment information:
• thread process ID view details
• thread -b view deadlock

Actual combat: the idea of ​​solving Full GC lag

• Whether Full GC caused by metaspace
• Whether a large number of "life and death" objects have reached the old age
  • A young GC to the objects in the survivor area, because too many objects in the survivor area will directly enter the old age
• The space guarantee mechanism leads to 2 Full GCs
  • Since the memory of the old generation is smaller than the average promotion size, one fullGC and then young GC
  • Promoted to the old age after young GC, Full GC again
• Whether the big object has reached the old age