APNS开源包的内存泄露问题

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/aalansehaiyang52/article/details/48803575

APNS(全称:Apple Push Notification Service),主要是用于往苹果设备推送push消息通知!


基本流程:



今天要聊的问题集中在第4个环节,我们自己的服务器往苹果的消息中心推送通知。


现状:

历史原因,push的代码散落在各个应用中,随着新消息通道不断接入,开发、维护成本较高,开始考虑构建push中心,

封装dubbo接口对外提供服务,对外屏蔽各种差异,将所有的push业务逐步收扰到push中心。

过程漫长,开始接入的是个人业务,每天的调用量不大,服务器还表现正常;

8月底,BI的推送管理后台开始对接进来并发布上线,由于BI是针对各种营销活动批量推送的,一次任务少则几万,多则上千万,

此时服务器开始暴露一些问题。


下面开始介绍优化过程:


1)第一次线上问题暴露,现象:短信报警,查看dubbo注册中心无provider服务,登录线上机器,load飙高到了40,ps看了jvm进程在,但dubbo日志里,服务注册失败。

查看gc,一直触发Full gc,old空间却释放不了


解决:重启集群。之前的策略是发送过来的数据会封装到一个线程任务里,由ThreadPoolExecutor慢慢消化,怀疑一次发送的token过多(一次400),生产速度快于消费速度,导致对象积累。联系BI的稀土同学,将一次任务的数量调整为100,并且每次调用接口后休眠100ms。


2)另外查看了jvm的参数,修改启动脚本,将原来的堆大小由1G调整为2G,新生代由原来的300M调整为1G

-Xms2g -Xmx2g -Xmn1g -XX:+UseParallelOldGC


了解BI的机器配置,24核cpu 64G内存,配置很高但只有一台,采用的是dubbo默认的随机路由方式,1对多,担心负载不均衡,

注:线上dubbo注册中心观察过,并不是所有的机器同时宕机,而是一个逐步的过程

调整路由策略,改为轮询方式:

更多内容可以参考 dubbo的开发手册

<dubbo:reference id="***" interface="******" loadbalance="roundrobin" />


3)这次持续的时间长了点,不过在任务跑了4个小时后,系统的old区占用到70%多,开始担心一会Full GC是否会正常回收。

由于采用的是UseParallelOldGC 并行回收方式(适用于吞吐量大应用类型),不象CMS可以设置空间使用比例主动触发回收。

但我们可以通过dump内存快照方式手动触发一次Full GC

jmap -dump:live,format=b,file=heap.bin <pid>




很不幸,Full GC 清理一次后 old区依然有 68%+,可以肯定,发生内存泄露

开始安装mat插件,分析内存快照,具体可参考《MAT使用教程

发现有大量的SSLSocketImpl实例对象无法回收,整个链路占了heap 50%+


4) 这个问题比较棘手,因为我们使用的是一个外部开源框架;

只能网上先查查资料,看看有没有其他人遇到过类似问题;

很不幸没有找到现成答案,幸运的是在github上找到了源代码。

https://github.com/fernandospr/javapns-jdk16

不过也只有代码,并没有过多文档介绍,不过这不重要

自己动手,丰衣足食。


分析代码,发现两处疑点:

a)NotificationThreads 里面会根据预传的线程数量,创建n个线程,每个线程负责往一定数量设备发送消息,主线程为了收集n个线程的最终发送结果,NotificationThreads继承了ThreadGroup,并将对象实例传到每个子线程构造器中,对主线程wait,当所有的子线程执行完毕后,通过notifyAll唤醒所有进程,继续后面的流程。

貌似没有什么明显问题,但是mat的分析结果ThreadGroup里面有大量其它线程,担心会有干扰。决定采用一种更靠谱更安全的方式,通过CountDownLatch来控制。









b)在子任务结束后(无论是正常结束还是非正常结束),在finally里面进行后续操作,关闭socket连接;

    另外 对 countDownLatch数量减1



重新打包并上传maven仓库(注意:需要修改pom配置文件)

<dependency>
  <groupId>com.github.fernandospr</groupId>
  <artifactId>javapns-jdk16</artifactId>
  <version>2.3.1-SNAPSHOT</version>
</dependency>

本地运行单元测试,可以成功推送消息


c)线上集群部署了一台机器,开始beta测试,运行一个1200W的推送任务


经过258次YGC后,年老代的空间使用率 依然很低,只有2%+

另外观察S0、S1、E发现,一次YGC后 to交换区基本能满足存放存活对象,不会有大量对象晋升到old区。


任务跑完后,gc情况,YGC 602次,没有触发Full GC



另外性能监控显示已经发送了800多万 条消息(注:图中统计的是接口调用次数,每次接口调用传100个用户token),响应时间正常。


总结:

a)线上报警,无论load彪的有多高,又或cpu使用率100%,千万不要慌,先保留一台问题机器,其它的机器全部重启,保证不影响外部使用

b)要从整个链路全面分析问题,多和身边的同事沟通讨论,也许会碰撞出灵感。


最后,非常感谢 错刀、金砖 ,处理过程中,提供了很多帮助!


展开阅读全文

没有更多推荐了,返回首页