为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。
- 【TiDB 版本】：4.0.0
- 【问题描述】： DM2.0 合库合表， 然后loader阶段， pool-size: 8 为什么qps一直跑不 上去，才几个，然后druation慢慢一直增加。
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
大量的连接线程，info 处于commit状态，tidb4.0 9个tikv，128GB内存主机， block-cache配置为32GB
Hi，可以检查一下dump文件（默认在worker目录的dump data下）的文件个数、大小吗。如果文件数目过小、文件过大，可能会影响速度，需要在 task 配置里的 extra-args 改为 extra-args: “–statement-size 1000000”
下个版本我们会自动处理好默认参数配置
之前64MB一个的时候，总的应该是一万个左右吧， 然后我今天换成3.1.2的版本了， 然后又报一个事务太大的错， 我就把DM的chunk-filesize: 32 从64改成32， 然后总数是 17592个 ，你的意思是文件数目过小，文件过大？会影响吗？ 然后我今天换成3.1.2的报"RawCause": “Error 8004: transaction too large, len:300001”, 这个错，有什么办法吗， 我这边的情况就是就是4.0的太慢，现在换成3.1.2的报事务太大。 分别有解决方法吗
extra-args: “–statement-size 1000000”
这个参数可以解决 3.1 超出 30w 行的问题，可以适当调整，具体参数含义可以看下官网。
建议继续使用 4.0 版本，可以上传下 tidb 集群的 overview 面板的完整截图我们看下 tidb 的基本情况，
dm 导入较慢，出了 dm 本身参数设置，也需要关注下游 tidb 的状态
TIDB表如果没有显式设置主键，有没有关系？会自动生成rowid做主键吗？ 因为合表问题，主键会有冲突。
extra-args: “–statement-size 1000000” 这个参数我看mydumper默认就是1000000, 要设置成多少呢？
应该是 load 的热点问题，dm 2.0 将 mydumper 换成了 dumpling：此参数的含义是： 控制 INSERT SQL 语句的大小，单位 bytes
-
512 或者 1024 试下，如果表较多，调整到原来的一半 500000 试下。满足 30w 行限制即可。
-
overview - system info 信息没有看到可以再截图看下。
-
从监控看到 hot region 较多，根据以下链接调整下：
https://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot-issues/#tidb-热点问题处理
https://docs.pingcap.com/zh/tidb/stable/high-concurrency-best-practices/#热点产生的实例