Note source: Silicon Valley JVM full tutorial, one million playback, the whole network peak (Song Hongkang detailed Java virtual machine)

Synchronous update: https://gitee.com/vectorx/NOT…

https://codechina.csdn.net/qq…

https://github.com/uxiahnan/N…

[TOC]

5. Analyze GC logs

5.1. The GC classification

For the implementation of HotSpot VM, there are two types of GC based on the collection region: Partial GC and Full GC.

  • Partial GC: Garbage collections that do not collect the entire Java heap. It is further divided into:

    • Minor GC/Young GC: It is only the garbage collection of the Cenozoic (Eden/S0, S1)
    • Major GC/Old GC: Just Old GC garbage collection. Currently, only the CMS GC has the behavior of collecting old age separately. Note that many times a Major GC is confused with a Full GC, and it is important to distinguish between a vintage collection and a whole heap collection.
  • Mixed GC: Collect the entire new generation and part of the old generation. Currently, only the G1 GC has this behavior
  • Full GC: Collects the entire Java heap and method area garbage collection.

5.2. GC log classification

MinorGC

Minorgc (or Young GC or YGC) log:

[Times: 31744K->2200K (121856K), 0.0139308 secs] User sys = = 0.05 0.01, real = 0.01 secs]

FullGC

[Full GC (Metadata GC Threshold) [PSYoungGen: 5104K->0K (132096K) ] [Par01dGen: 416K->5453K (50176K)]5520K->5453K (182272K), [Metaspace: 20637K->20637K (1067008K)], 0.024588secs] [Times: User sys = = 0.06 0.00, real = 0.02 secs]

5.3. GC log structure analysis

Look at the garbage collector through the log

  • Serial collector: The New Generation displays “[DefNew”, which is the Default New Generation
  • ParNew collector: The New Generation displays “[ParNew”, i.e. Parallel New Generation
  • Parallel Scavenge collector: The new generation displays “[PSYoungGen”, which is used in JDK1.7
  • Parallel Old Collector: Show “[ParoldGen”
  • G1 collector: displays “Garbage-first heap”

Look through the log to see the GC reason

  • Allocation Failure: Indicates that the GC is caused by the fact that there is not enough space in the generation to store the data that needs to be allocated
  • Metadata GcThreshold: The Metaspace section is not enough
  • Fergonomics: GC caused by JVM adaptation
  • System: The System.gc() method was called

Look through the log to see before and after GC

From the diagram, we can see that the pattern of GC log format is generally: memory footprint before GC – > memory footprint after GC (total size of memory in this region)

[PSYoungGen: 5986K->696K (8704K) ] 5986K->704K (9216K)
  • In brackets: size of young generation heap before GC collection, size after GC collection, (total size of young generation heap)
  • Outside the brackets: GC collection size before young generation and old age, size after collection, (total size of young generation and old age)

<mark> note </mark> : Minor GC heap total memory = 9/10 young generation + old generation. The reason is that the Survivor section only evaluates the FROM part, and the JVM defaults to the ratio between the Eden and Survivor sections in the young generation, Eden:S0:S1=8:1:1.

Look through the log to see the GC time

There are three times in the GC log: USER, SYS, and REAL

  • User: The time spent by the process executing user-mode code (outside the core). This is the actual CPU time used to execute the process, excluding other processes and the time that the process blocked. In the case of garbage collection, this represents the total CPU time used by the GC thread to execute.
  • SYS: CPU time consumed by a process in kernel state, that is, the CPU time spent executing system calls or waiting for system events in the kernel
  • Real: The clock time of the program from start to finish. This time includes time slices used by other processes and the time the process is blocked (such as waiting for I/O to complete). For parallel GC, this number should be close to (user time + system time) divided by the number of threads used by the garbage collector.

The real time of a GC event is smaller than the sys time+user time. The real time of a GC event is smaller than the sys time+user time. The real time of a GC event is smaller than the sys time+user time. If you have real > sys+user, your application may have one of the following problems: a heavy IO load or insufficient CPU.

5.4. GC log analysis tool

GCEasy

GCeasy is an online GC log analyzer that provides memory leak detection, GC pause analysis, JVM configuration optimization recommendations, and more. Most of the features are free.

Official website: https://gceasy.io/

GCViewer

GCViewer is an offline GC log analyzer for visualizing Java VM options -verbose: GC and data generated by.NET -Xloggc:<file>. You can also calculate performance metrics related to garbage collection (throughput, cumulative pauses, longest pauses, and so on). This feature is useful when tuning application-specific garbage collection by changing the generation size or setting the initial heap size.

The source code download: https://github.com/chewiebug/GCViewer

Running version download: https://github.com/chewiebug/GCViewer/wiki/Changelog

GChisto

  • There is no place to download the official website, you need to pull down from SVN compilation
  • But this tool seems to be not very well maintained, there are a lot of bugs

HPjmeter

  • The utility is powerful, but it can only open the GC log generated by the following arguments, -verbose: gc-xloggc :gc.log. The gc.log generated by adding other parameters cannot be opened
  • HPJMeter integrates with the previous HPJTune feature to analyze garbage collection log files generated on HP machines