文章描述了一个公司使用类似Dubbo的RPC服务遇到的问题，即上游系统报告调用超时，发现是由于CMS垃圾回收器触发的FullGC导致的时间延迟。分析发现服务每10天左右有一次长达15秒的FullGC，可能因内存使用到swap区而延长了扫描时间。解决方案是改用G1垃圾回收器，并通过压测验证其性能稳定性。
公司的联机RPC服务是一个类似Dubbo的服务，默认是的垃圾回收器是CMS。一天上游系统说发现多笔调用我们RPC服务超时。于是根据对方提供信息查看日志，发现请求虽然在合理时间处理完了。但是 开始处理时间 和 上游业务系统 请求时间存在时间差，相差10秒左右。
于是查看服务日志，发现有一个节点日志有30秒左右没有输出日志。然后查下gc日志，发现了这个时间点发生了一次30秒左右的fullgc。进而分析了历史fullgc记录，发现服务10天左右发生一次fullgc，每次时间在15秒。因为堆内存设置了4G，这个fullgc时间确实有点长，并且压测环境也只是在3秒左右。网上查了一些文章，猜测原因可能是部分内存用到了swap区，所以在fullgc时需要扫描磁盘。所以花费时间较长。
修改方案：
G1在压测环境连续压测24小时，只在刚启动时，metaspace做过一次fullgc。
将CMS改为G1.
扫一扫
2650
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
