【 TiDB 使用环境】生产环境 /测试/ Poc
生产环境
【 TiDB 版本】
5.4.0
【复现路径】做过哪些操作出现的问题
./dumpling -u root -P 4000 -h 127.0.0.1 --filetype sql -t 1 -o /data/bak -r 20000 -F256MiB --filter “test.*” --tidb-mem-quota-query 2147483648 --params “tidb_distsql_scan_concurrency=1”
【遇到的问题：问题现象及影响】
在使用dumpling导出sql文件时，tidb节点出现oom现象。 。
【资源配置】
tidb节点规格 4c16g 导出数据 70g，多表
【附件：截图/日志/监控】
数据库中每张表的数据量并不一致，有的几百m，有的十几个g。
-T 选项，降低并发看看呢
-t 已经指定为1了。 -T为指定表。
本次迁移数据的目的为，版本升级，由v5.4升级至v6.5.5，为保证集群安全，搭建新的高版本集群，并迁移数据，完成集群升级。 我测试了用 v5.4.0版本的dumpling、 v6.5.5版本的dumpling，都有这样的问题。
看下tidb oom前的日志
嗯，看来是-t是指定并发的，看下dashboard中的慢查询，看看哪个SQL导致的OOM
可以定位到明确的slowlog，同时也找到了server oom时快照保留下来的信息。在 /tmp目录下。
但是，单纯执行sql时，是没有问题的。
具体sql如下
select * from test WHERE id >= 2330606 AND id < 2734876 ORDER BY id;
那个时间的heap看下 啥占的内存高
这个需要使用什么工具查看呢？
可以把文件上传下
heap2023-11-28T15:38:21+08:00 (278.7 KB)
有没有可能是dumpling出发到了tidb-server的某些bug，导致内存泄漏呢？
dumpling 可以用v7.1.2或者更高的试试，我导出18T数据都没崩
–params “tidb_enable_chunk_rpc=0” 用这个试试
1 个赞