Interpretation of GC log observations for JVM tuning

If the parameters are set reasonably, there are no timeout logs in the system, the GC frequency is not high, and the GC time is not high, then there is no need to optimize the GC.
If the GC time exceeds 1-3 seconds, or GC is frequent, optimization must be performed.

1. Parameter interpretation

1. Typical parameter settings for Jvm tuning;
   -Xms: Minimum value of heap memory: By default, when the available memory in the heap is less than 40%, the heap memory will begin to increase until it reaches the size of -Xmx.
   -Xmx:Maximum value of heap memory: The default value is total memory/64 (and less than 1G). By default, when the available memory in the heap is greater than 70%, the heap memory will begin to decrease until it is reduced to the size of -Xms;
   -Xmn: The maximum value of the new generation memory: including the Eden area and the sum of the two Survivor areas. The configuration is written as: -Xmn1024k, -Xmn1024m, -Xmn1g
   -Xss: Stack memory for each thread: The default is 1M. Generally speaking, it does not need to be changed. A smaller thread stack means more threads can be created

The size of the entire heap = young generation size + old generation size. The size of the heap does not include the metaspace size. If the young generation is increased, the old generation will decrease accordingly. The official default configuration is old generation size/young generation. Generation size = about 2/1;
it is recommended to use Xms and Xmx to set the minimum and maximum values ​​respectively in the development and testing environment, but in the online production environment,The values ​​set by Xms and Xmx must be the same to prevent jitter;

2. GC log
   -XX:+PrintGCDetailsTurn on the GC log to create a more detailed GC log. By default, the GC log is turned off
   -XX:+PrintGCTimeStamps-XX:+PrintGCDateStamps: Turn on the GC time prompt.
   The opening time allows us to more accurately judge the time between several GC operations. Two parameters The difference is that
   the timestamp is a value relative to 0 (according to the time when the JVM is started), while the date stamp is an actual date string. Since the date stamp needs to be
   formatted, its efficiency may be slightly affected. However, this operation is infrequent, and its impact is difficult for us to perceive.
   -XX:+PrintHeapAtGCPrint the GC log of the heap.
   -Xloggc:./logs/gc.logSpecify the GC log path.

3. jdk11 gc log printing
   -Xlog:gc*:file=gc.log:time,uptime,pid,tid,tags:filecount=5,filesize=10M

gc.logIs the log printing location

2. Print the log

package com.zhk.study.log;

import java.util.ArrayList;
import java.util.List;

//测试代码
public class TestHeap {
    
    

  public static void main(String[] args) {
    
    
    List<Heap> list = new ArrayList<Heap>();
    while (true) {
    
    
      list.add(new Heap());
    }
  }
}

class Heap {
    
    
  String HeapName = "Java Heap 测试";
}

1.jdk8

Configure jvm parameters

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

1. Log interpretation

2022-08-05T13:45:23.336+0800: 4.866: [GC (Metadata GC Threshold) [PSYoungGen: 136353K->20975K(405504K)] 160049K->48437K(720384K), 0.0092260 secs] [Times: user=0.00 sys=0.02, real=0.02 secs]

2022-08-05T13:45:23.336+0800: 本次GC发生时间
4.866: 举例启动应用的时间
[GC【表示GC的类型，youngGC】 (Metadata GC Threshold) 元空间超阈值
[PSYoungGen: 136353K->20975K(405504K年轻代总空间)] 160049K->48437K(720384K)整堆), 0.0092260 secs本次垃圾回收耗时]
[Times: user=0.00本次GC消耗CPU的时间 sys=0.02系统暂停时间, real=0.02 secs实际应用暂停时间]

2. FullGC log meaning

2022-08-05T20:24:47.815+0800: 6.955: [Full GC (Metadata GC Threshold) [PSYoungGen: 701K->0K(72704K)] [ParOldGen: 38678K->35960K(175104K)] 39380K->35960K(247808K), [Metaspace: 56706K->56706K(1099776K)], 0.1921975 secs] [Times: user=1.03 sys=0.00, real=0.19 secs]

2022-08-05T20:24:47.815+0800:
6.955: 刚启动服务就Full GC【整堆回收！！】

[Full GC (Metadata GC Threshold) Metaspace空间超限！
[PSYoungGen: 701K->0K(72704K)] 年轻代没有回收空间
[ParOldGen: 38678K->35960K(175104K)] 39380K->35960K(247808K), 老年代也没有到阈值，整堆更没有到阈值
[Metaspace: 56706K->56706K(1099776K)], 0.1921975 secs]
[Times: user=1.03本次GC消耗CPU的时间 sys=0.00系统暂停时间, real=0.19 secs实际应用暂停时间]

2. jdk11 defaults to G1 recycling

The startup parameters are modified to

-Xlog:gc*:file=gc.log:time,uptime,pid,tid,tags:filecount=5,filesize=10M

1. Log interpretation

[2023-09-14T11:38:32.994+0800][0.017s][12940][11992][gc,heap] Heap region size: 1M
[2023-09-14T11:38:33.001+0800][0.024s][12940][11992][gc     ] Using G1
[2023-09-14T11:38:33.001+0800][0.024s][12940][11992][gc,heap,coops] Heap address: 0x0000000701c00000, size: 4068 MB, Compressed Oops mode: Zero based, Oop shift amount: 3
[2023-09-14T11:38:33.201+0800][0.225s][12940][8148 ][gc,start     ] GC(0) Pause Young (Normal) (G1 Evacuation Pause)
[2023-09-14T11:38:33.202+0800][0.225s][12940][8148 ][gc,task      ] GC(0) Using 3 workers of 3 for evacuation
[2023-09-14T11:38:33.215+0800][0.238s][12940][8148 ][gc,phases    ] GC(0)   Pre Evacuate Collection Set: 0.0ms
[2023-09-14T11:38:33.215+0800][0.238s][12940][8148 ][gc,phases    ] GC(0)   Evacuate Collection Set: 12.7ms
[2023-09-14T11:38:33.215+0800][0.239s][12940][8148 ][gc,phases    ] GC(0)   Post Evacuate Collection Set: 0.2ms
[2023-09-14T11:38:33.215+0800][0.239s][12940][8148 ][gc,phases    ] GC(0)   Other: 0.3ms
[2023-09-14T11:38:33.215+0800][0.239s][12940][8148 ][gc,heap      ] GC(0) Eden regions: 12->0(10)
[2023-09-14T11:38:33.215+0800][0.239s][12940][8148 ][gc,heap      ] GC(0) Survivor regions: 0->2(2)
[2023-09-14T11:38:33.215+0800][0.239s][12940][8148 ][gc,heap      ] GC(0) Old regions: 0->7
[2023-09-14T11:38:33.215+0800][0.239s][12940][8148 ][gc,heap      ] GC(0) Humongous regions: 4->4
[2023-09-14T11:38:33.215+0800][0.239s][12940][8148 ][gc,metaspace ] GC(0) Metaspace: 6551K->6551K(1056768K)
[2023-09-14T11:38:33.215+0800][0.239s][12940][8148 ][gc           ] GC(0) Pause Young (Normal) (G1 Evacuation Pause) 16M->12M(256M) 14.012ms
[2023-09-14T11:38:33.215+0800][0.239s][12940][8148 ][gc,cpu       ] GC(0) User=0.03s Sys=0.02s Real=0.01s

This log describes the details of garbage collection events for Java applications. Let me explain what each part means:
[2023-09-14T11:38:32.994+0800]- This is the timestamp, indicating the time the log was recorded.

[0.017s]- This is a timestamp relative to the time of the log record, indicating the relative time at which the log record occurred.

[12940][11992] - These two numbers may be thread identifiers, identifying the thread performing garbage collection.

[gc,heap] Heap region size: 1M- This means that the Java heap partition size is 1MB.

[gc] Using G1- This means Java uses the G1 garbage collector.

[gc,heap,coops] Heap address: 0x0000000701c00000, size: 4068 MB, Compressed Oops mode: Zero based, Oop shift amount: 3- This describes the Java heap address, size and compressed pointer (Compressed Oops) information.

[gc,start] GC(0) Pause Young (Normal) (G1 Evacuation Pause)- This is the beginning of the garbage collection event. GC(0) indicates the 0th garbage collection. Pause Young (Normal) (G1 Evacuation Pause) indicates that this is a normal G1 garbage collection event in the Young generation.

[gc,task] GC(0) Using 3 workers of 3 for evacuation- This means that in this garbage collection event, there are 3 worker threads used to perform object migration.

[gc,phases]- This series of lines describes the different stages of garbage collection, including Pre Evacuate Collection Set, Evacuate Collection Set, Post Evacuate Collection Set, etc.

[gc,heap]- This line provides information about heap memory, including changes in Eden, Survivor, Old, Humongous and other areas.

[gc,metaspace]- This line provides information about the metaspace (Metaspace), including its size changes.

[gc] Pause Young (Normal) (G1 Evacuation Pause) 16M->12M(256M) 14.012ms- This line provides summary information about the garbage collection event, including changes in heap memory usage before and after collection, and the duration of the event.

[gc,cpu]- This line provides the CPU usage of garbage collection events.

Collectively, these log records provide detailed information about garbage collection events in Java applications, including timestamps, thread identities, garbage collector types, heap memory conditions, event duration, etc. This information is very useful for analyzing and tuning the performance of Java applications.

3. Optimization

Optimizing garbage collection performance often requires careful analysis of application behavior and garbage collection logs, and then taking appropriate actions based on the results of the analysis. Here are some possible optimization suggestions, but please note that specific optimization strategies will vary based on the needs and behavior of your application:

• Analyze garbage collection patterns: First, you must understand the garbage collection patterns of your application. As can be seen from the log, the G1 (Garbage-First) garbage collector is used here. Different garbage collectors are suitable for different applications, so it is important to ensure that you choose the best collector for your application's needs.

• Adjust the heap size: Depending on the needs of your application, you may need to adjust the heap size (-Xms and -Xmx parameters). If your application triggers garbage collection frequently, you may need to increase the heap size to reduce the frequency of collections. But be aware that excessive increases in heap size may also cause long garbage collection pauses, so careful adjustments are needed.

• Analyze garbage collection pause time: From the log, you can see the pause time of each Young area and Mixed area garbage collection. The goal of optimization is to reduce these pause times to improve application responsiveness. You can use parameters to control the garbage collection pause time, such as using the -XX:MaxGCPauseMillis parameter.

• Analyze the memory allocation pattern: Check the allocation of Eden, Survivor and Old areas in the log. If you find that frequent objects enter the Old area, you may need to adjust the size of each area or adjust the proportion of the young generation to reduce the survival time of objects in the Old area.

• Check Metaspace usage: Metaspace usage can be seen from the log. If Metaspace usage continues to grow, you may need to increase the Metaspace size or check for classloader leaks.

• Analyze object lifecycle: Understanding the lifecycle patterns of objects in your application can help determine when to perform garbage collection. If the life cycle of the object is very short, you can adopt a strategy that focuses more on the Young zone. If the object life cycle is long, you need to ensure that the management of the Old area is efficient enough.

• Monitor and tune: Continuously monitor application performance using performance monitoring tools and garbage collection logs. If performance issues are discovered, garbage collection parameters can be adjusted based on real-time data.

• Parallelism and Concurrency: Depending on the characteristics of your application, you can choose between parallel garbage collection or concurrent garbage collection. Parallel collectors are suitable for multi-core systems, while concurrent collectors are suitable for applications that require minimal pause times.

• Analyze throughput: Understanding the throughput requirements of your application allows you to choose an appropriate garbage collection strategy. Some garbage collectors are better suited for high throughput, and some are better suited for low pause times.

• Version Upgrade: Consider upgrading your JVM version to the latest stable version, as new versions often bring performance and garbage collection improvements.

To summarize, optimizing garbage collection performance is a complex process that requires a deep understanding of your application's behavior and needs. It is recommended to perform multiple tests and adjustments in development and test environments to find the optimal garbage collection configuration. At the same time, keep a close eye on performance metrics in your production environment and make necessary adjustments as application load changes.

4. Judgment of gc times

gc times