次要 GC 暂停时间太高。 可能的原因？

Question

I Am experiencing a regular high minor GC pause times(~ 9seconds).

The application is a server written in Java, executing 3 transactions/seconds.

Eventhough there's no I/O excessive activity

Heap parameters are:

-Xms1G
-Xmx14G
-XX:+UseConcMarkSweepGC
-XX:+DisableExplicitGC
-XX:+PrintGC
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails

What are the possible reasons for such minor gc pause times values?

Answer 1

For questions in category "Why my GC pause that long?" you should always provide some snippets for GC logs.

As a pure speculation, here are few reasons why minor GC may be abnormally slow:

• JVM were suspended from execution by OS (ei CPU starvation, swapping, virtual server freeze)
• There are some issue with putty JVM at safepoint (unlikely looking at your pause pattern though)
• Object survival spikes
• Reference object processing overhead (you need add -XX:+PrintReferebceGC to get reference processing info into GC log)

Answer 2

As the other answer says, without GC log snippets it's not possible to answer this definitively. Some things to think about:

Assuming no impact from the underlying OS (scheduling, CPU thrashing), the time taken for a minor collection will be proportional to the amount of live data in the young gen. when the collector runs (every live object in the young gen. gets copied during a minor GC). Looking at the graph of your old gen. you are seeing consistent growth which would indicate you are promoting significant amounts of data during minor GC. You're either creating a lot of long-lived objects or you're maintaining references unnecessarily.

To reduce the pauses you could try reducing the size of the Eden space (so there is less potential data to copy on each minor GC) and also reduce the tenuring threshold so that objects get moved out of the survivor spaces more quickly. The downside of this will be your minor GCs will happen more frequently so you will probably see a degradation in throughput.

I would also change the -Xms value. You clearly need more than 1Gb in your heap so it would be best to set it to 14Gb to avoid the heap having to be resized by the JVM as the amount of data increases.

Answer 3

Try using

-XX:+UseG1GC -XX:MaxGCPauseMillis=1000 

This will try to keep max GC pause below 1s.

You need to assign enough memory using -Xmx and set the MaxGCPauseMillis as per need.

Answer 4

IMHO:

• There is no sufficient evidence that there is indeed minor GC "pause time". What is shown is Garbage Collection Time, and GC time.= GC Pause time. Garbage collection activity time and garbage collection pause time are two different beasts - or in technical words, I should say that these are JVM ergonomics/performance goals.
• Minor GC pause time is commonly negilible and it is the major GC pause time that affects the application responsiveness.
• There is something called as JVM/Ergonomics goals, and "Throughput Goal" is one of the three goals, so I think in this case at max what can be said is that throughput goal is not going very good for young generation as lot of time is spent on GC.