long Young garbage collection pauses due to JSON loading in Java 11

Question

In my application I have implemented a background task which reads a JSON file to memory and parses it into Java objects of relevant (specified in JSON) classes. I use Jackson to parse JSON. The JSON file is about 6MB in size. My JSON files look more or less like this:

{ 
    Class_type_A: {
        Entry_1: x,
        Entry_2: x,
        ...
        Entry_200000: x
    },
    Class_type_B: {
        Entry_1: x,
        Entry_2: x,
        ...
        Entry_200000: x
    }
}

My background task runs every 30 minutes, and this is also where my JVM shows significantly big (up to 2 seconds) pause for garbage collection, which unfortunately impacts live traffic to my application. I am sure garbage collection pauses are related to JSON loading, because I compared task with JSON loading to the same task without. I have never attempted debugging such a thing before and I don't quite know where to start.

I use Zulu 11 OpenJDK and G1 garbage collector.

Here are my questions:

1. Is there any specific logs that I should look into, to understand what is happening?
2. Why does reading JSON have such impact on GC?
3. How do you suggest I can validate that JSON parsing is responsible for such long GC pauses?
4. Do you think Jackson library streaming API for reading JSON could save me from garbage collection spikes? Especially so, if I have only 2 nodes in my JSON?

Answer 1

It would be helpful to know what your heap size, vCPUs and any other GC setting are. The number of vCPUs affect the number of threads available for GC, and thus throughput.

G1 prioritizes throughput over latency, which can affect your pause time. An oversized heap can allow the young space (Eden) to grow rather large and require a large pause time.

Try setting -XX:MaxGCPauseMillis=200.

For debugging with gc.log, enable these print options:

java -Xlog:gc*,safepoint:gc.log:time,uptime:filecount=100,filesize=128K

or for Java 8:

-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintGCApplicationConcurrentTime

When you review the logs,

• check for 'G1 Humongous Allocation' in the log, if you see any, increase -XX:G1HeapRegionSize.
• if Eden is larger than Old space, consider a smaller heap