Debezium Mysql BinLog同步引擎的内存爆满，频繁GC导致CPU爆高

女爷i 2024-04-07 11:49 55阅读 0赞

## 现象，第一步 ##

同步任务的http接口查询任务列表接口突然变卡，很久才相应，进入服务器后执行top命令发现CPU已经爆满。

top (查看进程占用资源)

机器是4核，所以占用了400%

![wecom-temp-138912e7f885f37ae16b86cb7872acc1.png][]

top -H -p 276965 (查看进程ID下的子进程占用资源)

4个子线程，每个各占了100%

![wecom-temp-06673636548e93c8a3584ee412ca405c.png][]

printf “%x\\n” 276970

jstack 276965 | grep 439ea -A 100

通过查看当前线程执行的详情，发现输出的是gc线程

jmap -heap 276965

jmap的使用方式：[blog.csdn.net/heihaozi/ar…][blog.csdn.net_heihaozi_ar]

查看jvm当前的堆内存情况，老年代、新生代皆已满

![wecom-temp-9498631e96940ca4b078158f017e544a.png][]

上面的命令具体怎么用参考这篇blog：[blog.csdn.net/cainiao1412…][blog.csdn.net_cainiao1412]

## 第二步 ##

既然是堆内存满了，此刻就要拿到整个堆内存的快照，执行

jmap -dump:live,format=b,file=heap.dump 276965

下载到本地使用 VisualVM 打开，有很亮眼的TableMapEventData，但是此时还是不清楚何处引起的泄露。

VisualVM的使用方式：[blog.csdn.net/weixin\_4546…][blog.csdn.net_weixin_4546] ， [t.zoukankan.com/wangzun-p-1…][t.zoukankan.com_wangzun-p-1]

![image.png][]

此时使用工具MAT继续打开dump，这里看就比较明显，是一个名为MySql…EventSource类中的tableMap…ByTableId的一个HashMap巨大，

MAT的使用方式：[zhuanlan.zhihu.com/p/482860374][zhuanlan.zhihu.com_p_482860374] , [blog.csdn.net/w2009211777…][blog.csdn.net_w2009211777]

![image.png][image.png 1]

## 第三步 ##

根据MAT的提示，找到该处代码，可以看见在收到TABLE\_MAP这个Event事件时，会将数据放到HashMap中

![image.png][image.png 2]

数据既然存，就也需要清理，在源码中只找到了一处清理该Map的地方，当收到ROTATE事件时，清理Map，那么由此可见如果不收到ROTATE事件，Map将会无限增长

![image.png][image.png 3]

什么是ROTATE事件？

参考：[www.freesion.com/article/125…][www.freesion.com_article_125]

也就是说我们的Map会等到binlog文件大小达到 max\_binlog\_size 的值时，才会进行清空，或者手动执行flush logs，但是生产环境中一般不会去手动执行，max\_binlog\_size 的值我们的库默认为 256MB。

![image.png][image.png 4]

什么是 Table Map Event?

意思就是 Table Map Event 会存储表的元数据，例如数据库名、表名、字段等，后续的Row Event会通过table id 和其关联，取到对应的元数据，因此这个存储是有必要的，

但是table id会随着缓存淘汰、刷新等机制出现变化，也就是说同一个库的同一个表的table id会不停的变化，因此table id并不是唯一的，所以我们的Map会随着程序的运行可能存储很多明明是同库同表，但是因为table id不同导致存map中很多重复的数据，导致占用内存越来越大。

![image.png][image.png 5]

![image.png][image.png 6]

## 解决方式 ##

Debezium对mysql binlog同步默认使用的是 [github.com/osheroff/my…][github.com_osheroff_my] ， 这个库很久没有更新了，

但是Flink CDC使用的也是 Debezium，也就是说也依赖了这个库，所以可能也会存在这种问题，

两种解决方式，一是增大内存，均匀任务，让内存足够存储这么多的冗余数据，二是修改源码，在特定时机，例如新的table id过来时，将老的table id对应的数据清除？

针对binlog的同步，还有一个工具叫做maxwell，在生产环境中使用并没有出现这种问题，追踪了一下源码，也是类似的原理，但是maxwell使用我们使用了docker做资源隔离，每个进程给了2g，而Debezium任务则跑在同一个jvm中，因此更多倾向于均匀分配一些资源。

## 最终解决方式 ##

我们的系统采用的版本是1.9.0.Final，在查看其源码时，在 MySqlStreamingChangeEventSource 类中，针对 ROTATE 事件发生时，并没有对map进行clear处理，所以导致了内存泄露，为了避免升级版本影响过大，我们采用了修改源码的方式，针对ROTATE发生时，对map进行清除。

![在这里插入图片描述][2f27d1bc3f76411886ee45907823a8b9.png]

![在这里插入图片描述][4f086af71cfc4c519ab94977364c9f0b.png]

[wecom-temp-138912e7f885f37ae16b86cb7872acc1.png]: https://img-blog.csdnimg.cn/img_convert/3cba42644e363c53fdb8ede2069f57b6.webp?x-oss-process=image/format,png
[wecom-temp-06673636548e93c8a3584ee412ca405c.png]: https://img-blog.csdnimg.cn/img_convert/700d882f1d88e0d1a4051059a87c86b7.webp?x-oss-process=image/format,png
[blog.csdn.net_heihaozi_ar]: https://blog.csdn.net/heihaozi/article/details/123593231
[wecom-temp-9498631e96940ca4b078158f017e544a.png]: https://img-blog.csdnimg.cn/img_convert/a0755732e030b83d028b29c730dad65f.webp?x-oss-process=image/format,png
[blog.csdn.net_cainiao1412]: https://blog.csdn.net/cainiao1412/article/details/98885073
[blog.csdn.net_weixin_4546]: https://blog.csdn.net/weixin_45463105/article/details/115891456
[t.zoukankan.com_wangzun-p-1]: http://t.zoukankan.com/wangzun-p-11613051.html
[image.png]: https://img-blog.csdnimg.cn/img_convert/c4d3ee5b56164db4a019c4227308a977.webp?x-oss-process=image/format,png
[zhuanlan.zhihu.com_p_482860374]: https://zhuanlan.zhihu.com/p/482860374
[blog.csdn.net_w2009211777]: https://blog.csdn.net/w2009211777/article/details/123912643
[image.png 1]: https://img-blog.csdnimg.cn/img_convert/02a747db527298cf6c41a21311fc5e64.webp?x-oss-process=image/format,png
[image.png 2]: https://img-blog.csdnimg.cn/img_convert/5d68135caa328788abaf3c029aff5048.webp?x-oss-process=image/format,png
[image.png 3]: https://img-blog.csdnimg.cn/img_convert/65f6713b084c01e285b1918fcc675ce3.webp?x-oss-process=image/format,png
[www.freesion.com_article_125]: https://www.freesion.com/article/1255403964/
[image.png 4]: https://img-blog.csdnimg.cn/img_convert/8fc2c0afb2b2eb7749ac93e38f408aa9.webp?x-oss-process=image/format,png
[image.png 5]: https://img-blog.csdnimg.cn/img_convert/ca23817f8add6d38d4078d69b57113d1.webp?x-oss-process=image/format,png
[image.png 6]: https://img-blog.csdnimg.cn/img_convert/1de74b9bd7028c8ea5161bf5aba6d173.webp?x-oss-process=image/format,png
[github.com_osheroff_my]: https://github.com/osheroff/mysql-binlog-connector-java
[2f27d1bc3f76411886ee45907823a8b9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/fb556a5c68324d11b4f5115b9e7bd24e.png
[4f086af71cfc4c519ab94977364c9f0b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/3262d662c9eb4f1eac2c301d2df599ab.png