一次JVM GC长暂停的排查过程-阿里云开发者社区

开发者社区> 开发与运维> 正文

一次JVM GC长暂停的排查过程

简介: 现象 通过CAT埋点,发现在35~36分钟时候,出现JVM的GC耗时异常 通过跳板机登录机器,找到GC日志进行查看,如下图 在显示的最后一行中,我们看到其中user=0,sys=0,real=4.31s,表示JVM经历了长达4s多的STW,也即在这段时间内,该机器是无法对外提供服务的,请求到达该机器,最终只能超时返回。

现象

通过CAT埋点,发现在35~36分钟时候,出现JVM的GC耗时异常

通过跳板机登录机器,找到GC日志进行查看,如下图

在显示的最后一行中,我们看到其中user=0,sys=0,real=4.31s,表示JVM经历了长达4s多的STW,也即在这段时间内,该机器是无法对外提供服务的,请求到达该机器,最终只能超时返回。

排查

根据经验,这种 real > user + sys 的情况,大概率是内存的swap和密集型的IO造成的,可以顺着这个思路进行排查,这时候就突显了系统监控的重要性了,通过查看IO监控

我们可以发现,在对应的时间上确实存在大量的IO操作。

为什么频繁IO会引起长时间GC

在发生GC时,需要把相关数据写入GC日志,在写入期间,因为write()系统调用导致了暂停。这种日志的写操作,即使在异步、缓存IO或非阻塞IO模式下,还是有可能因为系统机制(比如页面缓存的回写),导致长时间的阻塞。

如何减轻因为IO造成的影响?

1、检查本机是否有其它进程在疯狂写文件,如果有的话,最好进行分离;

2、可以将Java日志文件移动到一个单独的或高性能的磁盘驱动器,例如SSD, tmpfs,这样不至于在写GC日志时,write方法被阻塞住,导致长时间的STW;

欢迎工作一到五年的Java程序员朋友们加入Java架构开发:744677563

本群提供免费的学习指导 架构资料 以及免费的解答

不懂得问题都可以在本群提出来 之后还会有职业生涯规划以及面试指导

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章