APNS开源包的内存泄露问题

本文讲述了在处理大规模Apple Push Notification Service (APNS) 推送时遇到的内存泄露问题及其解决过程。通过调整dubbo服务、增大堆内存、引入CountDownLatch优化线程控制、确保Socket关闭等方式,成功解决了由于SSLSocketImpl实例导致的内存占用过高问题,避免了Full GC的频繁触发,提高了推送服务的稳定性和效率。
摘要由CSDN通过智能技术生成

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对多,担心负载不均衡,


                
  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值