一次高IO下的GC分析之旅

一次高IO下的GC分析之旅

编码前线 关注

2018.12.21 00:06 字数 597 阅读 45评论 0喜欢 0

起因：收到GC STW报警

【监控系统】Total time for which application threads were stopped: 67.7651070 seconds, Stopping threads took: 0.0000240 seconds

快速分析原因

此处不分析具体GC日志，主要分析方法:

• 从线上拷贝日志到本地

• 打包成gc.zip格式

• 上传到gceasy.io

•  

  

  image

找到原因

找到是因为缺IO或内存资源导致高IO，并不是GC本身过程耗时太多(上一步GC的报告中获得)：

 

image

通过监控系统，找到当时机器IO飙升(公司内部监控机器的平台，zabbix实时收集机器的一些状态)：

 

image

深层次原因

整个应用程序的停顿主要由两部分组成：由于JVM GC行为造成的停顿(T1->T2)，以及为了记录JVM GC日志(T3->T4)，系统调用write()被OS阻塞的时间。下面这张图展示了二者之间的关系。

 

image

解决方案

首先，JVM实现完全可以解决掉这个问题。显然，如果将写GC日志的操作与可能会导致STW停顿的JVM GC处理过程分开，这个问题自然就不存在了。例如，JVM可以将记录GC日志的功能放到另一个线程中，独立来处理日志文件的写入，这样就不会增加STW停顿的时间了。但是，这种采用其他线程来处理的方式，可能会导致在JVM崩溃时丢失最后的GC日志信息。最好的方式，可能是提供一个JVM选项，让用户来选择适合的方式,但这个方法基本没办法我们自己来处理。
由于后台IO造成的STW停顿时间，与IO的繁重程度有关，所以我们可以采用多种方式来降低后台IO的压力。例如，不要在同一节点上安装其他IO密集型的应用程序，减少其他类型的日志行为，提高日志回滚频率等等。

我们最后的解决办法是将GC日志文件放到其他低IO磁盘上，把gc日志放到图中的/data2,很明显从iostat来看它的磁盘IO压力很小。

 

image