CODEWITHSUNDEEP
javagarbage-collection
dbf
dbf

Reputation: 6499

Unexpected Full GC (Ergonomic)

I'm running application that consists of 3 stages: load initial data, update it using POST http requests, serve it using GET requests. After all data is set up (initial load + POST updates) I'm calling System.gc() and I see 

[Full GC (System.gc()) 2051102K->1082623K(3298304K), 13.3521960 secs]

So I expect that I need about 1000M for old gen and run my app with such setup (at 4G RAM docker container):

java -XX:MaxNewSize=2550m -XX:NewSize=2550m -Xms3750m -Xmx3750m -XX:+PrintGCTimeStamps -XX:+PrintGC -cp my.jar my.My

So I expect that from 3750M of heap 2550M will be used for new space to serve GET requests and 1200M will be for old gen. During the work of my application I have

[Full GC (Ergonomics) 2632447K->1086729K(3298304K), 2.3360398 secs]

So it looks very strange for me that full GC is triggered. My understanding is that because GET requests don't add any long-living data it should be just Minor GC when new generation is full. So I don't understand

1) Why it is running Full GC (Ergonomics) - does it want to change generation layout?

2) Why it is running when only 2632447K of 3298304K are occupied?

Upvotes: 2

Views: 3309

Answers (1)

Nir Alfasi
Nir Alfasi

Reputation: 53525

A few points:

  • GET/POST has nothing to do with it, the logic that you implemented for GET/POST is what matters... e.g. the GET method might have a memory leak...

  • Growing memory doesn't necessarily reduce GC (it doesn’t work in linearly)

  • GC usually freezes for ~1 sec per live GB, so the fact that you're having 13 secs freeze for 1 GB worths checking

  • The next step should be enabling GC log and analyzing it to have a better understanding of the issue

Upvotes: 2

Related Questions