DM-worker内存泄露

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】
测试

【概述】 场景 + 问题概述
1.有一个tidb-worker内存占用很高,同步状态query-status显示正常,但是syncdBinlogGtid没有增加
2.部署了6个dm-worker在同一台机器上,但是一直都只一个dm-worker进程有问题

【备份和数据迁移策略逻辑】
上游mysql同库分表到下游tidb单表

【背景】 做过哪些操作
正常sit测试,没有压测

【现象】 业务和数据库现象
同步阻塞,且只有一个dm-worker如此

【问题】 当前遇到的问题
同步阻塞

【业务影响】
没有同步

【TiDB 版本】
5.7.25-TiDB-v4.0.10

【DM 版本】
2.0.5

【机器信息】
Linux 1a01vlc1900zzzz 3.10.0-957.21.3.el7.x86_64 #1 SMP Tue Jun 18 16:35:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
memory:8G
CPU:4C

【附件】


pprof.dm-worker.alloc_objects.alloc_space.inuse_objects.inuse_space.001.pb.gz (696.2 KB)


若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

非常抱歉,看 profiling 像是 DM 在使用 leveldb 库时有问题。您可以尝试重启该 worker 看看能不能解决。

在下个版本中,我们会移除 leveldb 库的主要使用对象
https://github.com/pingcap/dm/issues/1932

1赞

重启能解决,但是生产已经使用了改版本的DM的,麻烦尽快修复呢。

重启之后还能稳定出现吗?

您这个 worker 上面运行的任务大概涉及多少张表、迁移的表结构可以提供一下吗,我们尝试复现一下

现在又出现了,内存占用28%+了。
这个task包含了上游一个mysql实例多个schema的表,schema数量是4,表数量大致是64+256+256+64+64+64+64+64。
生产是对不同schema拆成不同task来同步的,所以暂时没问题。测试环境为了方便管理,都放在一个task里边了。
表结构可能没法提供哈