一次漫长的dubbo网关内存泄露排查经历
?背景介绍
在微服务架构中,不同的微服务有不同的网络地址,而客户端则是通过统一的地址进行调用,在客户端与服务端之间需要有一个通信的桥梁,这就产生了微服务网关。微服务网关可以连接客户端与微服务,提供统一的认证方式,管理接口的生命周期,做更好的负载均衡、熔断限流,提供方便的监控,提供统一的风控入口。
今天要介绍的主角是dubbo微服务网关,来自公司内部自研的提供http协议到dubbo协议转换的微服务网关,跟本文相关的就是它的核心点:dubbo泛化调用。dubbo官网对泛化调用的描述为
“泛化接口调用方式主要用于客户端没有 API 接口及模型类元的情况,参数及返回值中的所有 POJO 均用map表示,通常用于框架集成。“
dubbo最常见的调用方式是引入服务提供方定义的jar包,用于描述接口,但如果是网关引入所有的dubbo提供者的jar包就很不现实,况且如果需要新增接口就需要重新发布网关,所以需要使用泛化调用来解决这个问题,官网提供的示例代码截图如下:
文章图片
image 问题描述
这款网关上线以来一直运行稳定,直到某一天出现了问题,频繁full GC,cpu上涨,错误率飙升,然而接口的调用量并没有上涨。立马重启机器,并且保留了一份内存dump文件,分析了一周没有结论,最近又出现了一次,情形类似。
文章图片
full gc频繁
文章图片
old区被填满
文章图片
cpu利用率上升,错误率上升 问题排查
- 从内存dump文件查起
文章图片
dump
文章图片
dump
RegistryDirectory对象多达7000多个,直接定位为RegistryDirectory可能存在内存泄露。再跟进一下这个对象的持有者
文章图片
image
发现是com.alibaba.dubbo.remoting.zookeeper.curator.CuratorZookeeperClient$CuratorWatcherImpl,搜索一下该类的对象
文章图片
image 这个对象也非常多。到这里就去查看dubbo的源码(本文dubbo源码基于2.6.6)。首先查找com.alibaba.dubbo.remoting.zookeeper.curator.CuratorZookeeperClient$CuratorWatcherImpl创建的地方
文章图片
image 只有一个地方创建,接着跟进addChildListener
文章图片
image 只有在订阅zookeeper的节点时会调用,继续查找订阅zookeeper的地方,发现有两处
- 一处是ReferenceConfig的createProxy会调用RegistryProtocol的doRefer,进而订阅zookeeper;
- 另一处是FailbackRegistry中会有一个线程不停地对订阅失败的path进行重试,在zk重新连接时会recover。
文章图片
image
dubbo应用在与zookeeper断开连接重新连上的时候会recover,recover里面执行的就是重新订阅zookeeper。这很好模拟,线下打断点测试一下在zookeeper端开重连的时候是否会重新生成CuratorWatcherImpl对象。结果当然是没有生成,因为dubbo应用会缓存CuratorWatcherImpl对象,对于相同的URL订阅,返回的都是相同的CuratorWatcherImpl对象,并不会重新生成。
- 从网络寻求答案
文章图片
image 否决了这个issue后又发现了一个issue, https://github.com/apache/dubbo/issues/4587
文章图片
image 但这个很快又被否决了,因为这里他的主要问题是reference未缓存,在dubbo的文档中针对这个是有提及的
文章图片
image 出问题的dubbo网关是对reference做了缓存(以interface+version+group+timeout作为key,timeout是为了能动态调整接口的超时时间),理论上不会重复生成reference
- “守株待兔“
文章图片
image
文章图片
image ZookeeperRegistry中有个zkListeners存储了订阅了哪些URL,如果能检测这个字段是不是就可以了?简单点,定时检测并打印日志。通过反射来获取这个变量
文章图片
image 代码改好,测试一下,放到线上一台机器守株待兔。经过一下午,终于抓到了
文章图片
image 发现其中一个service,被重复订阅了很多次,而且订阅的URL只有timestamp不一样,且只有一个服务会这样,怀疑跟服务本身有关,查看该服务,发现其没有provider
文章图片
image 难道没有provider的服务会出现重复订阅?线下复现试试,使用网关去调用一个没有provider的服务(省略复现过程),果然问题出现了!问题能复现就很好排查了,打断点根据调用栈就能找到订阅的地方
文章图片
image 在生成referenceConfig时会初始化proxy,如果初始化过就会忽略,问题就在createProxy
文章图片
image 如果check=true,且provider不存在,createProxy就会抛异常,createProxy底层去订阅了zookeeper,缓存了RegistryDirectory对象,如果不停订阅,内存就会被撑爆,看下这个报错在那几天是否很多
文章图片
image 好像也不是很多,单机加起来几百次,为什么会产生这么多RegistryDirectory对象,通过调试发现
文章图片
image 每次订阅的URL是生成的,也就是timestamp不同,且会被塞入urls这个变量缓存起来,然后循环这个urls进行refer(即订阅),也就是说第一次urls中有1个URL需要订阅,第二次就成了2,第三次是3,也就是高斯计算的那个1+2+3+4+...+100的问题,请求100次会产生5050个RegistryDirectory对象。
解决办法很简单,将check=true改为check=false。
总结
- 这个是dubbo的bug,在2.7.5版本中已经将订阅的URL中的timestamp去掉了,只会对一个URL订阅一次,issue即之前提到的https://github.com/apache/dubbo/issues/4587,但当时这个issue并没有解决我们的疑问;
- 泛化调用时将reference的check设置为false,否则可能会出现内存泄露;普通调用(xml配置)则无影响,因为check=true如果没有provider应用会启动失败;
- 问题排查难易程度:通过监控、代码、日志直接定位的问题 < 可稳定复现的问题 < 不可稳定复现的问题(偶尔出现) < 不可复现的问题(只出现一次),本文的问题属于不可稳定复现的问题。
当dubbo多注册中心碰上标签路由
以为是青铜,没想到是王者的dubbo标签路由
【一次漫长的dubbo网关内存泄露排查经历】记一次spring注解@Value不生效的深度排查
推荐阅读
- 【故障公告】周五下午的一次突发故障
- 我要我们在一起(二)
- dubbo基本认识
- 洱海不是海,,人群没有你
- 我的拖延症如何控制了我,又一次
- 跟身体谈恋爱
- 记一次赛课失利
- 秋已动夏未走
- 第一次组织同学们乘车
- 恩|恩 有点喜欢你