This article documents the process and tools used to analyze whether GC is working properly when a deviation application stutters.

I was alerted in the morning and woke up. I used gceasy. IO to analyze the GC log of the server, as reported in the 2017-05-28 GC.log report

This report clearly pointed out the application problem, that is, a long GC pause occurred at around 07:09 on February 28, 2017, as shown below:

  1. Reduce Long GC Pause this article lists several possible causes of long GC pauses:

    • High object creation rate, report shows my application is ok
    • In the Heap area, the young generation is smaller; -xmn :NewRatio -xx :NewRatio -xmn :NewRatio -xx :NewRatio -xmn :NewRatio -xx :NewRatio
    • GC algorithm selection problem, I use G1 collector: G1 collector is suitable for high concurrency scenarios, should be fine
    • Process Considerations
    • Fewer GC threads
    • Background I/O congestion. According to the system monitoring, THE I/O delay and CPU usage are both high at the same time. This problem is suspected.

  2. This article first introduces the difference between user-time, system-time and real-time. Because multiple threads perform GC, under normal circumstances, Real-time should be less than user-time + system-time (for example, if user-time + system-time is 2 seconds and there are 5 threads executing GC, then real-time should be 400 milliseconds). However, there are certain scenarios in which real-time is greater than the sum of user-time and system-time. If there are multiple such cases in GC logs, the reasons may be: I/O spikes; The CPU resources are exhausted. Procedure

JVM parameters or IO issues may be causing long GC pauses, but IO issues are more likely.