JVM 足够的内存但频率满 gc

Question

JVM Options: -Xms512M -Xmx512M -XX:PermSize=70M -XX:MaxPermSize=70M

jstat -gc 8260 5000

S0C:512.0 S1C:512.0 S0U:0.0 S1U:0.0 EC:174080.0 EU:0.0 OC:349696.0 OU:45191.1 PC:71680.0 PU:34882.2 YGC:2216225 YGCT:6754.909 FGC:2216144 FGCT:160651.466 GCT:167406.375

S0C:512.0 S1C:512.0 S0U:0.0 S1U:64.0 EC:174080.0 EU:0.0 OC:349696.0 OU:45187.3 PC:71680.0 PU:34882.2 YGC:2216253 YGCT:6755.047 FGC:2216172 FGCT:160653.488 GCT:167408.535

S0C:512.0 S1C:512.0 S0U:0.0 S1U:128.0 EC:174080.0 EU:0.0 OC:349696.0 OU:45189.6 PC:71680.0 PU:34882.2 YGC:2216281 YGCT:6755.180 FGC:2216200 FGCT:160655.542 GCT:167410.721

S0C:512.0 S1C:512.0 S0U:0.0 S1U:0.0 EC:174080.0 EU:1775.6 OC:349696.0 OU:45187.3 PC:71680.0 PU:34882.2 YGC:2216308 YGCT:6755.309 FGC:2216227 FGCT:160657.627 GCT:167412.936

S0C:512.0 S1C:512.0 S0U:128.0 S1U:0.0 EC:174080.0 EU:0.0 OC:349696.0 OU:45187.3 PC:71680.0 PU:34882.2 YGC:2216336 YGCT:6755.444 FGC:2216255 FGCT:160659.701 GCT:167415.146

Why JVM frequency full gc happened?

Answer 1

It is hard to tell, but one possible explanation is that you are repeatedly allocating and discarding very large arrays.

If I am interpreting the stats correctly, the Eden space is 174MB, the Survivor spaces are 0.5MB, and the Old space is 349MB. If you allocate an array that is too large to put into the Eden space, it will be allocated straight into Old space. If the Old space fills, that may trigger a full GC.

How big is "big"? Well it is complicated, because there is also the issue of the TLAB and its size, the -XX:PretenureSizeThreshold option and differences between different kinds of GC. Read "Java Garbage Collection Distilled" by Martin Thompson to get you started on the issues.

---

If this is not the problem then you need to do a deeper investigation of what is happening in your heap. Figure out what the mix of objects is, their rates and patterns of allocation / disposition, etc to try and figure out why so many are ending up in the Old space.

After 3-5 days works fine, this happens

That tends to suggest that something is building up in your application's in-memory data structures over those three to five days of operation. Investigate that scenario.

Answer 2

Your survivor spaces are very small. Just 512KB. If the survivor space fills up on a clean up of the Eden space it triggers a Full GC.

As your Eden spaces is ~300 x larger, I would be surprised if they were not filling up.

I would check that you are not creating a lot of very short lived objects which is why the JVM thinks hardly anything survives.

For example, see if you can parse/process your UDP packet without creating objects.

Answer 3

When heap and stack memory looks good, try to find memory leak about "Direct Memory". In my case, part of Netty5-ByteBuf didn't released.