业务背景
目前移动端的使用场景中会用到大量的消息推送,push消息可以帮助运营人员更高效地实现运营目标(比如给用户推送营销活动或者提醒APP新功能)。
对于推送系统来说需要具备以下两个特性:
- 消息秒级送到用户,无延时,支持每秒百万推送,单机百万长连接。
- 支持通知、文本、自定义消息透传等展现形式。正是由于以上原因,对于系统的开发和维护带来了挑战。下图是推送系统的简单描述(API->推送模块->手机)。
问题背景
推送系统中长连接集群在稳定性测试、压力测试阶运行一段时间后随机会出现一个进程挂掉的情况,概率较小(频率为一个月左右发生一次),这会影响部分客户端消息送到的时效。
推送系统中的长连接节点(Broker系统)是基于Netty开发,此节点维护了服务端和手机终端的长连接,线上问题出现后,添加Netty内存泄露监控参数进行问题排查,观察多天但并未排查出问题。
由于长连接节点是Netty开发,为便于读者理解,下面简单介绍一下Netty。
Netty介绍
Netty是一个高性能、异步事件驱动的NIO框架,基于Java NIO提供的API实现。它提供了对TCP、UDP和文件传输的支持,作为当前最流行的NIO框架,Netty在互联网领域、大数据分布式计算领域、游戏行业、通信行业等获得了广泛的应用,HBase,Hadoop,Bees,Dubbo等开源组件也基于Netty的NIO框架构建。
问题分析
猜想
最初猜想是长连接数导致的,但经过排查日志、分析代码,发现并不是此原因造成。
长连接数:39万,如下图:
连接数
每个channel字节大小1456, 按40万长连接计算,不致于产生内存过大现象。
查看GC日志
查看GC日志,发现进程挂掉之前频繁full GC(频率5分钟一次),但内存并未降低,怀疑堆外内存泄露。
分析heap内存情况
ChannelOutboundBuffer对象占将近5G内存,泄露原因基本可以确定:ChannelOutboundBuffer的entry数过多导致,查看ChannelOutboundBuffer的源码可以分析出,是ChannelOutboundBuffer中的数据。
没有写出去,导致一直积压;
ChannelOutboundBuffer内部是一个链表结构。