6

一次漫长的 Dubbo 网关内存泄露排查经历

 3 years ago
source link: https://mp.weixin.qq.com/s/m2_7xef1vAfILDVTmMXTXw
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

转自:捉虫大师  作者:捉虫大师

背景介绍

在微服务架构中,不同的微服务有不同的网络地址,而客户端则是通过统一的地址进行调用,在客户端与服务端之间需要有一个通信的桥梁,这就产生了微服务网关。微服务网关可以连接客户端与微服务,提供统一的认证方式,管理接口的生命周期,做更好的负载均衡、熔断限流,提供方便的监控,提供统一的风控入口。

今天要介绍的主角是dubbo微服务网关,来自公司内部自研的提供http协议到dubbo协议转换的微服务网关,跟本文相关的就是它的核心点:dubbo泛化调用。dubbo官网对泛化调用的描述为

“泛化接口调用方式主要用于客户端没有 API 接口及模型类元的情况,参数及返回值中的所有 POJO 均用map表示,通常用于框架集成。“

dubbo最常见的调用方式是引入服务提供方定义的jar包,用于描述接口,但如果是网关引入所有的dubbo提供者的jar包就很不现实,况且如果需要新增接口就需要重新发布网关,所以需要使用泛化调用来解决这个问题,官网提供的示例代码截图如下:

aiMfYn3.png!web

问题描述

这款网关上线以来一直运行稳定,直到某一天出现了问题,频繁full GC,cpu上涨,错误率飙升,然而接口的调用量并没有上涨。立马重启机器,并且保留了一份内存dump文件,分析了一周没有结论,最近又出现了一次,情形类似。

JrENNrE.png!web

full gc频繁

FB7JVnQ.png!web

old区被填满

ny63Mrq.png!web

cpu上涨,错误率上升

问题排查

  • 从内存dump文件查起

从监控上基本能断定是内存问题,那就分析一下当初dump出来的内存文件,使用eclipse的mat插件分析

INRBVrj.png!web

YfymErv.png!web

RegistryDirectory对象多达7000多个,直接定位为RegistryDirectory可能存在内存泄露。再跟进一下这个对象的持有者

YfmymeY.png!web

发现是com.alibaba.dubbo.remoting.zookeeper.curator.CuratorZookeeperClient$CuratorWatcherImpl,搜索一下该类的对象

eMNVjmJ.png!web

这个对象也非常多。到这里就去查看dubbo的源码(本文dubbo源码基于2.6.6)。首先查找com.alibaba.dubbo.remoting.zookeeper.curator.CuratorZookeeperClient$CuratorWatcherImpl创建的地方

Iniee27.png!web

只有一个地方创建,接着跟进addChildListener

aYRnuer.png!web

只有在订阅zookeeper的节点时会调用,继续查找订阅zookeeper的地方,发现有两处

  • 一处是ReferenceConfig的createProxy会调用RegistryProtocol的doRefer,进而订阅zookeeper;

  • 另一处是FailbackRegistry中会有一个线程不停地对订阅失败的path进行重试,在zk重新连接时会recover。

首先怀疑第二处

n2ENVvI.png!web

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

  • 从网络寻求答案

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

eyq6jiY.png!web

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

ABNJnyu.png!web

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

FBBNnea.png!web

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

  • “守株待兔“

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

2Q3A3mi.png!web

ymqy6fR.png!web

ZookeeperRegistry中有个zkListeners存储了订阅了哪些URL,如果能检测这个字段是不是就可以了?简单点,定时检测并打印日志。通过反射来获取这个变量

77rIBbQ.png!web

代码改好,测试一下,放到线上一台机器守株待兔。经过一下午,终于抓到了

fyInIrv.png!web

发现其中一个service,被重复订阅了很多次,而且订阅的URL只有timestamp不一样,且只有一个服务会这样,怀疑跟服务本身有关,查看该服务,发现其没有provider

U3UnMbz.png!web

难道没有provider的服务会出现重复订阅?线下复现试试,使用网关去调用一个没有provider的服务(省略复现过程),果然问题出现了!问题能复现就很好排查了,打断点根据调用栈就能找到订阅的地方

F7ZBrqy.png!web

在生成referenceConfig时会初始化proxy,如果初始化过就会忽略,问题就在createProxy

AjMnUnn.png!web

如果check=true,且provider不存在,createProxy就会抛异常,createProxy底层去订阅了zookeeper,缓存了RegistryDirectory对象,如果不停订阅,内存就会被撑爆,看下这个报错在那几天是否很多

yieIbuU.png!web

好像也不是很多,单机加起来几百次,为什么会产生这么多RegistryDirectory对象,通过调试发现

B7JVbeI.png!web

每次订阅的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应用会启动失败;

  • 问题排查难易程度:通过监控、代码、日志直接定位的问题 < 可稳定复现的问题 < 不可稳定复现的问题(偶尔出现) < 不可复现的问题(只出现一次),本文的问题属于不可稳定复现的问题。

nI3Yb2v.jpg!web

架构摆渡人,助你通往架构师方向的领路人。 本号会定期分享架构相关的文章,专注于架构方向,关注我们,下一个架构师就是你。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK