DMDRS几个参数对性能的影响

概要

本文测试的是dmdrs在数据迁移的过程中一些参数对迁移速率的影响，由于迁移与同步执行原理不太相同，同步时对redo日志和归档日志进行解析，而迁移是直接读取表数据，不需要解析日志。剩下的性能相关的参数大多与日志解析相关，大差不差。

环境：

源端：cent0S7 DM8 DMDRS5

目的端：cent0S7 DM8 DMDRS5

均使用虚拟机，虚拟机软件为VMWare Station 16

准备工作

数据准备

创建测试表

CREATE TABLE "SYSDBA"."TEST_DSR"
(
"ID" INT PRIMARY KEY AUTO_INCREMENT ,
"DESCRIPE" VARCHAR(100),
)

使用manager工具在源库中生成10w条数据

对照组

先后启动目标库和源库的DMDRS服务，打开drcsl控制台，使用以下命令进行迁移

cp cpt_dm8 "sch.name='SYSDBA' and tab.name='TEST_DSR'" DROP|CREATE|INSERT

先删除，再建表，最后插入数据，确保每一次的迁移内容都是相同的，控制单一变量

等一会后，打开log/drs_xxx.log查看装载耗时，如下图所示，10w条数据所需时间大概为3秒，每秒迁移4w条左右

参数测试

send

enable_compress

是否压缩

对网卡进行限速

由于我们是1对1单向数据迁移，只需修改源端的出站带宽即可,下面中的ens33替换为你的网卡名

# 查看网卡
ip a

这里限制为10mbit，即1.25MB/s

# 1. 清理旧规则（可选）
sudo tc qdisc del dev ens33 root 2>/dev/null

# 2. 添加 HTB 根 qdisc
sudo tc qdisc add dev ens33 root handle 1: htb default 10

# 3. 添加根 class（总带宽）
sudo tc class add dev ens33 parent 1: classid 1:1 htb rate 10mbit ceil 10mbit

# 4. 添加默认子 class（可选，但推荐）
sudo tc class add dev ens33 parent 1:1 classid 1:10 htb rate 10mbit ceil 10mbit

验证是否限速成功

查看网卡设置

tc qdisc show dev ens33

出现htb开头的一串则说明设置成功

可使用iperf3测试网络实际速度

# 作为客户端测试上传（向服务器发数据）
iperf3 -c <server_ip> -t 10

# 作为服务端（另一台机器）：
iperf3 -s

或者没有安装iperf3，也可以使用xftp等文件传输工具传一个文件观察一下速度

这里可能会出现一个问题，限速成功了但是过一会就失效了，很多现代 Linux 发行版（如 Ubuntu 20.04+、CentOS 8+、Debian 11+）默认启用了 NetworkManager 或 systemd-networkd，它们会在网络事件（如 DHCP 刷新、链路状态变化、重启网络服务）时自动重置网卡的 qdisc 配置，导致你手动加的 tc 规则被清空。解决方法如下

# 禁用 NetworkManager 对该接口的管理
# 编辑配置文件
sudo nmcli dev set ens33 managed no

sudo systemctl restart NetworkManager

验证限速成功后，我们使用drs对数据进行迁移

cp cpt_dm8 "sch.name='SYSDBA' and tab.name='TEST_DSR'" DROP|CREATE|INSERT

迁移完同样查看log

由于限制了带宽，迁移速度被明显地限制了，10w条数据来到了21秒

现在我们来尝试对数据进行压缩，减少网络带宽瓶颈的影响

修改源端drs的配置文件（在服务脚本中指定的配置文件，我这里是新建了一个drs.xml），在send标签中加入<enable_compress>1</enable_compress>

重新启动源端drs，同样的命令进行数据迁移

cp cpt_dm8 "sch.name='SYSDBA' and tab.name='TEST_DSR'" DROP|CREATE|INSERT

查看目的端日志

本次迁移只用了3秒！由此可见，在带宽瓶颈，cpu仍有冗余的情况下，可以使用压缩的方式来提高迁移速率

cipher

加密算法，缺省为不加密。

测试使用DES_ECB加密算法迁移10w条数据需要多长时间

同样的，在send标签中加入以下标签

<cipher>DES_ECB</cipher>
--删除之前加入的标签
<enable_compress>1</enable_compress>

由于加密对cpu的开销较大，我们这里将网络恢复到不限速状态，避免网络瓶颈对该参数结果的干扰，记得要删掉压缩的参数

sudo tc qdisc del dev ens33 root 2>/dev/null

重启源端drs服务，仍然执行相同的迁移命令

cp cpt_dm8 "sch.name='SYSDBA' and tab.name='TEST_DSR'" DROP|CREATE|INSERT

观察目的端log

约为7秒，慢了整整一倍，可见加密对于性能的开销还是蛮大的。

在实际操作中，如果条件允许的话，比如在内网进行数据迁移，不需要加密的情况下，选择不加密明显是一个更好的选择。

package_size

发送消息的应用层封包大小。发送消息时，会将多条消息打包一次发送。适当增加该参数值，会减少交互次数。设置过大，则可能会浪费内存资源。取值范围：64 ～8192，单位：KB，默认值为1000。

同样地，在send中加入以下标签，记得清除之前加入的chip选项

<package_size>8192</package_size>

重启源端drs服务器执行迁移

cp cpt_dm8 "sch.name='SYSDBA' and tab.name='TEST_DSR'" DROP|CREATE|INSERT

观察目的端输出log

用时3s，在10w数据量的情况下，打包大小1000或者8192对速度没有明显影响。

我们将参数的大小改为最小值64再试一次，启动迁移观察日志

这次用时来到了8s，出现了明显的速率下滑

思考：为什么64和1000有明显区别，而1000和8192没有

每次发送的数据量越大，完成 10 万条数据所需的发送次数越少。每次网络交互都有固定开销（如 TCP 握手/确认、系统调用、上下文切换等）。

从1000到64，发包次数明显提升，各种固定开销在小包场景下占比更高，次数更多，导致整体耗时增加

从1000到8192，理论上来说相差了8倍应该会有明显的性能差异，实测却没有，这是由于性能效益的边际递减，在达到一定阈值后，性能的瓶颈已经从网络交互次数来到了其他地方，可能是：源端读取速率，目的端执行速率，cpu瓶颈，网络带宽瓶颈等。

在我们实际的操作中，可以监控 CPU、内存、网络带宽、目标库写入延迟，以识别真实瓶颈，从而对该参数进行合理的优化

load

load_thr

装载读取源数据库数据的线程数。取值范围：1～255，默认值为32。

我们设置为1测试一下，记得删除前面的pagesize参数，恢复默认值

<load>
    <load_thr>1</load_thr>
</load>

设置为1后，重启drs服务，执行迁移命令

cp cpt_dm8 "sch.name='SYSDBA' and tab.name='TEST_DSR'" DROP|CREATE|INSERT

观察目的端drs输出

用时3秒钟，和32线程没什么显著差别，每秒速率也基本一致

这有可能是因为：

本次迁移中只有一张表，查询本身无法分片化，只能由一个线程执行，其他线程都是空闲状态

而且10w条数据算规模较小，此时整个迁移过程的耗时主要花在网络传输、目标写入、事务提交等环节，而非源读取。

此时增加读取的线程数并不会对速率产生太大影响

在实际操作中，在确认硬件和数据库软件性能仍有冗余（如源库是高性能集群）的情况下，在迁移大量表，大数据的情况下，可以适当增加并行线程数来提升速率，单机单表迁移往提高线程数往往没有收益

nets

消息投递与下一级DMDRS服务建立的网络连接数。参数nets的值对应EXEC的装载站点数，增加nets值会增加装载时EXEC的内存需求。取值范围1-3，默认值为1。

我们设置为3进行测试

<load>
   <nets>3</nets>
</load>

重启后执行命令

cp cpt_dm8 "sch.name='SYSDBA' and tab.name='TEST_DSR'" DROP|CREATE|INSERT

观察日志

观察到这次迁移也是用了3s（到完成装载），同时也可以看到exec模块启动了3个站点，但下面的执行中只有一个站点在输出日志，说明其他两个站点都属于空闲状态。

可见速率没有提升的原因与上一个类似，单表无法多个站点一起执行，瓶颈是目标数据库的执行速率。

总结

本文测试了dmdrs在数据迁移的过程中一些参数对迁移速率的影响，在单表10w数据的迁移场景下，有的对效率有明显影响，有的则没有，对此分析了原因，现在做出总结，对dmdrs性能调优提出几条建议：

首先要确认迁移瓶颈，避免盲目调优，先通过监控（CPU、内存、I/O、网络、数据库会话）识别真实瓶颈。
如果是网络瓶颈，可以采取压缩的方式，用cpu性能换取一部分网络性能
考虑环境迁移限制，如果内存充足可以调大封包大小，如果cpu性能和数据库性能冗余可以调大并行读取/执行线程数
单库单表的情况下很多并发参数都是无用的，一方面因为无法多线程执行，再多的线程也是空闲，还有可能占用系统资源，另一方面是数据库软件本身瓶颈了。
目的端的写入速度也有可能成为瓶颈之一，避免盲目调大源端的输出速率造成目的端内存堆积，oom风险

DMDRS性能参数实测