This is the 11th day of my participation in the Gwen Challenge in November. Check out the details: The last Gwen Challenge in 2021

Today, we’re going to analyze the GC logs, and the GC logs will help us determine the internal health of the JVM so that we can make adjustments to the JVM based on the actual running of the program to meet the actual performance requirements.

This article focuses on the branches of the GC log, which sections to look at, which GC tools to use for analysis, what conclusions to draw, etc., as a review of what we have learned so far, let’s take a look.

Interpretation of GC logs

The reason for GC is that memory allocation failed, and the GC algorithm we use is java8 GC, so we need to check what GC algorithm we use, we use JPS plus jinfo to query.

Using JPS, find the process ID of our system, in this case 3296

As you can see, parallel GC is used.

Then we know that STW is required for parallel GC, so we can see that the STW time is 13 milliseconds, what happens with those 13 milliseconds? We can see the size of the Young area [PSYoungGen: 262144K->43516K(305664K)] compressed about 219M, the size of the entire young region is about 305M, our entire heap is set to 1G: 262144K->80620K(1005056K), then the whole heap is about 80M compressed, so the whole heap is about 182M compressed, which is interesting. Our young region is 262, and the entire heap is 262. After compression, our young region is inconsistent with the heap memory. If we do not 🈲, we will ask: where is the missing data?

We can think of it this way: the young generation subtracted more data than the entire heap, how much more, 37M more, where did the 37M go, ran to the old age, or we can calculate it like this: The entire heap is compressed to 80M, 43M in our younger generation, and 37M in our older generation.

Then we have multiple GC, a FullGC happens, and then we look at the young region, which had 36M of data, and then we look at the Old region, [ParOldGen: 613141K->337990K(699392K)], reducing the data by nearly half, then our metadata area is our non-heap, almost unchanged, and then the entire Full GC is 41 milliseconds, so reducing the Full GC helps improve program performance.