记一次应用卡顿问题的排查

这篇文章记录了一次排查应用卡顿问题时，分析GC是否正常的过程和使用到的工具。

早上被报警叫醒，使用gceasy.io分析了服务器的gc日志，报告见：2017-05-28 gc.log报告

这份报告里明确得指出了应用的问题，即在2017.2.28 07:09左右发生了长时间的GC停顿，入下图所示：

1. 点击进入reduce long GC pause，这篇文章列举了几个可能引起长时间GC停顿的原因：

   • 高速的对象创建速率，报告显示我的应用没问题
   • Heap区域，年轻代较小；jdk 1.8只配置了Xmx和Xms相同大小，2048，没有指定-Xmn或-XX:NewRatio，可能有影响；
   • GC算法选择问题，我使用G1回收器：G1回收器适合高并发场景，应该没问题
   • Process Swapping，进程内存置换
   • 较少的GC线程
   • 后台IO阻塞，根据系统监控发现在同一时间IO延时、占用CPU都飙高，怀疑是这个问题。

2. 点击进入fix this problem，这篇文章首先介绍了user-time、system-time和real-time的区别，由于多线程进行GC过程，因此在正常情况下，real-time应该小于user-time + system-time（例如：如果user-time + system-time为2秒，而有5个线程在执行GC算法，那么real-time应该为400毫秒）。但是在一些特定场景下会出现real-time大于user-time + system-time之和，如果在GC日志中出现多个这样的情况，原因可能是：IO飙高；CPU资源耗尽。

综上分析，可能是JVM参数或io问题引起的GC长时间停顿，IO问题可能性更高。