一次漫长的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的地方,发现有两处

  1. 一处是ReferenceConfig的createProxy会调用RegistryProtocol的doRefer,进而订阅zookeeper;
  2. 另一处是FailbackRegistry中会有一个线程不停地对订阅失败的path进行重试,在zk重新连接时会recover。

首先怀疑第二处


image

dubbo应用在与zookeeper断开连接重新连上的时候会recover,recover里面执行的就是重新订阅zookeeper。这很好模拟,线下打断点测试一下在zookeeper端开重连的时候是否会重新生成CuratorWatcherImpl对象。结果当然是没有生成,因为dubbo应用会缓存CuratorWatcherImpl对象,对于相同的URL订阅,返回的都是相同的CuratorWatcherImpl对象,并不会重新生成。

  • 从网络寻求答案

换个思路重新开始,去网上看看又没人遇到相同的问题,网上搜了一下,发现了 https://github.com/apache/dubbo/issues/376 跟我的问题几乎一样,难道是发布导致的问题?但经过几次对比否决了,因为平时发布都没事,偏偏这时候出事?而且两次爆发时网卡流量并不高。

image

否决了这个issue后又发现了一个issue, https://github.com/apache/dubbo/issues/4587

image

但这个很快又被否决了,因为这里他的主要问题是reference未缓存,在dubbo的文档中针对这个是有提及的

image

出问题的dubbo网关是对reference做了缓存(以interface+version+group+timeout作为key,timeout是为了能动态调整接口的超时时间),理论上不会重复生成reference

  • “守株待兔“

问题真的陷入僵局,好在看到了这么一篇文章,《netty堆外内存泄露排查盛宴》,作者在面对无法排查的问题时,在线上植入一段监控代码来协助定位问题。于是在想能不能也植入一段代码,看看这么多订阅到底是什么。通过对dubbo的源码翻看,找到这么一个可以获取订阅的点

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不生效的深度排查

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 213,047评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,807评论 3 386
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 158,501评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,839评论 1 285
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,951评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,117评论 1 291
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,188评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,929评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,372评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,679评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,837评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,536评论 4 335
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,168评论 3 317
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,886评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,129评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,665评论 2 362
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,739评论 2 351

推荐阅读更多精彩内容