jdk17下netty导致堆内存疯涨原因排查 | 京东云技术团队

原创

于 2023-09-05 11:43:02 发布 · 461 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#网络 #JDK #JDK17 #netty #Java

文章讲述了天网风控灵玑系统在升级到JDK17+ZGC后，遇到内存疯涨和低延迟问题。通过排查，发现是由于跨数据中心数据同步时，nettyeventLoop的消费能力不足，导致内存占用过高。根源在于JDK高版本对直接内存申请的限制，通过调整JVM参数和优化连接策略解决了问题。

背景：

介绍

天网风控灵玑系统是基于内存计算实现的高吞吐低延迟在线计算服务，提供滑动或滚动窗口内的count、distinctCout、max、min、avg、sum、std及区间分布类的在线统计计算服务。客户端和服务端底层通过netty直接进行tcp通信，且服务端也是基于netty将数据备份到对应的slave集群。

Pasted image 20230823174329.png

低延迟的瓶颈

灵玑第1个版本经过大量优化，系统能提供较大的吞吐量。如果对客户端设置10ms超时，服务端1wqps/core的流量下，可用率只能保证在98.9%左右，高并发情况下主要是gc导致可用率降低。如果基于cms 垃圾回收器。当一台8c16g的机器在经过第二个版本优化后吞吐量超过20wqps的时候，那么大概每4秒会产生一次gc。如果按照一次gc等于30ms。那么至少分钟颗粒度在gc时间的占比至少在(15*30/1000/60)=0.0075。也就意味着分钟级别的tp992至少在30ms。不满足相关业务的需求。

jdk17+ZGC

为了解决上述延迟过高的相关问题，JDK 11 开始推出了一种低延迟垃圾回收器 ZGC。ZGC 使用了一些新技术和优化算法，可以将 GC 暂停时间控制在 10 毫秒以内，而在 JDK 17 的加持下，ZGC 的暂停时间甚至可以控制在亚毫秒级别。实测在平均停顿时间在10us左右，主要是基于一个染色指针和读屏障做到大多数gc阶段可以做到并发的，有兴趣的同学可以了解下，并且jdk17是一个lts版本。

问题：

采用jdk17+zgc经过相关的压测后，一切都在向着好的方向发展，但是在一种特殊场景压测，需要将数据从北京数据中心同步给宿迁数据中心的时候，发现了一些诡异的事情

服务端容器的内存疯涨，并且停止压测后，内存只是非常缓慢的减少。
相关机器cpu一直保存在20%（已经无流量请求）
一直在次数不多的gc。大概每10s一次

Pasted image 20230823101641.png

排查之旅

内存泄漏排查

第一反应是遇到内存疯涨和无法释放该问题时，首先归纳为内存泄漏问题，感觉这题也简单明了。开始相关内存泄漏检查：先dump堆内存分析发现占用堆内存的是netty相关的对象，恰好前段时间也有个同学也分享了netty下的不合理使用netty byteBuf导致的内存泄漏，进一步增加了对netty内存泄露的怀疑。于是开启netty内存泄漏严格检查模式（加上jvm 参数Dio.netty.leakDetection.level=PARANOID），重新试跑并没有发现相关内存泄漏日志。好吧~！初步判定不是netty内存泄漏。

Pasted image 20230823104911.png

jdk与netty版本bug排查

会不会是netty与jdk17兼容不好导致的bug? 回滚jdk8测试发现的确不存在这个问题，当时使用的是jdk17.0.7 版本。正好官方发布了jdk17.0.8版本，并且看到版本介绍上有若干的 Bug Fixes。所以又升级了jdk一个小版本，然而发现问题仍然在。会不会是netty的版本过低？正好看见gitup上也有类似的issue# https://github.com/netty/netty/issues/6125WriteBufferWaterMark’s 并且在高版本疑似修复了该问题，修改了netty几个版本重新压测，然而发现问题仍然在。