一次netty"引发的"诡异old gc问题排查过程

应用：新美大push服务-长连通道sailfish
日推送消息：180亿
QPS峰值: 35W
最大实时在线用户：2200W

push服务简单结构为

客户端sdk<=>长连通道<=>pushServer

1.客户端sdk: 负责提供客户客户端收发push的api
2.长连通道：负责维持海量客户端连接
3.pushServer：负责给业务方提供收发push的rpc服务，与长连通道通过tcp连接，自定义协议，具体的push服务设计另起文章

首先依据这篇文章把push长连通道应用的jvm参数调到最优，见海量连接服务端jvm参数调优杂记, 剩下的都是这篇文章之后所发生

一

2016年9月2号6:00 左右陆续收到两台机器的报警，上去看一下cat监控

改造之前gc情况

发现 在凌晨4:11分左右，这台机器cms old区域到达old gc阀值1525M(old区域设置为2048M, -XX:CMSInitiatingOccupancyFraction=70，所以阀值为1433M，前一分钟为1428.7M)，于是进行old gc，结果进行一次old gc之后，啥也没回收掉，接下来一次次old gc，old区不减反增，甚是诡异！

gc日志

在4:10:29开始频繁old gc(其实这是第二次old gc了，之前已经有过一次，不过可以忽略，我就拿这次来分析)，发现old gc过后，old区域大小基本没变，所以这个时候可以断定old区里面肯定有一直被引用的对象，猜测为缓存之类的对象

二

使用 jmap -dump:live,format=b,file=xxx [pid] 先触发一次gc再dump
重点关注这台10.32.145.237

dump 的时候，花了long long的时间,为了不影响线上引用，遂放弃。。。

三

9月3号早上又发现old gc，于是连忙起床去dump内存，总内存为1.8G，MAT载入分析

堆内存

光这两个家伙就占据了71.24%，其他的可以忽略不计
然后看到NioSocketChannel这个家伙，对应着某条TCP连接，于是追根溯源，找到这条连接对应的机器

NioSocketChannel 堆内存

然后去cmdb里面一查

cmdb

发现是pushServer的机器。长连通道服务器是用netty实现，自带缓冲区，对外连接着海量的客户端，将海量用户的请求转发给pushServer，而pushServer是BIO实现，无IO缓冲区，当pushServer的TCP缓冲区满了之后，TCP滑动窗口为0，那么长连服务器发送给这台机器的消息netty就一直会保存在自带的缓冲区ChannelOutBoundBuffer里，撑大old区。接下来需要进一步验证

四

9月5号早上，来公司验证，跑到10.12.22.253这台机器