通过DM把MySQL的数据同步至TiDB，load相关参数如下：
loader:
pool-size: 2
dir: ./dumped_data
import-mode: sql
on-duplicate: replace
当同步任务进行至Load阶段，下游TiDB部分节点IO几乎被打满：
服务器磁盘的写流量也非常大：
目前下游TiDB已经在跑生产业务了，IO打满的影响还是比较大的。官方文档看DM的Load阶段貌似没有什么好的限流措施，这种情况还能做些什么优化？
手动导入吧。
手工导入是用myloader做导入吗？因为下游在跑业务，高峰期Load需要暂停一段时间，很多导入方式不支持暂停。
另外DM的all模式全量+增量全部能搞定，手工导入的话自己还要再处理增量的部分，后续还要好多个系统要迁移，这样会加大运维工作量 
load size 不行调整为 1，还不行就手动吧。没啥办法了。
麻烦提供下 dm/tidb 的版本信息，以及相关节点的具体配置。dm 的详细配置麻烦也发下
另外从截图看，tidb/tikv 是跑在同一个节点上的？
dm 在 load 阶段是执行 SQL语句，此时不应该有这么高的磁盘 IO 操作，按说升高的应该是网络 IO（写 TiKV）。在截图这段期间有添加 Index 的操作吗？
6.2.0 之前的版本 DM 无法配置 load （使用 lightning）并发度，6.2 之后可以通过 pool-size 配置。如果版本较低的话，建议升级下
dm是v6.5.0
TiDB是v6.1.2
tidb和tikv是独立部署的，一台tikv服务器部署3个tikv节点，每个节点都是独立的2T nvme盘。
这段时间下游tidb没有进行DDL操作。
其中一台tikv服务器的流量：
同一台服务器的io使用率：
我们之前用dm迁移速度很慢，用的自己写的dts工具快不少，还有很多商用的数据同步工具，可以找一下
