达梦数据库（DM8）性能测试综合报告

一、实验目的
1.1 实验背景
随着国产化替代战略的深入推进，达梦数据库作为我国自主研发的关系型数据库管理系统，在政府、金融、能源、电信等关键行业得到广泛应用。达梦数据库在功能上与 Oracle 高度兼容，支持标准 SQL、事务处理、存储过程等完整数据库能力，是国产数据库领域的重要代表。
在数据库选型与运维过程中，性能是衡量数据库能否承载真实业务系统的关键指标。数据库性能测试能够量化数据库在特定硬件环境、特定负载模型下的处理能力、响应时间与稳定性，为容量规划、架构选型与参数调优提供依据。
1.2 实验目的
本次实验旨在通过业界主流的性能测试工具（BenchmarkSQL TPC-C 压测、sysbench、JMeter），对达梦数据库的多种部署形态（单机主备集群、单机实例、DSC 共享存储集群）进行全面性能评估。
二、TPC-C 压测
2.1 TPC-C 测试概述
TPC-C是事务处理性能委员会制定的OLTP基准测试标准，模拟商品批发公司的核心业务系统，包括新订单、支付、订单状态查询、发货和库存检查五种事务类型。核心指标为 tpmC，即每分钟新订单数。
本次实验使用BenchmarkSQL 5.0开源工具进行压测，该工具是TPC-C标准的Java实现，支持达梦数据库的标准JDBC驱动。测试环境为20仓库，每仓库约100MB数据，总数据量约2GB。
2.2 实验环境
本次实验在本地虚拟机上部署达梦数据库，操作系统为 CentOS Linux 7，通过 MobaXterm 远程连接虚拟机进行管理和压测，使用 PyCharm 进行数据分析和图表生成。
2.2.1 软件环境

本次压测服务器硬件配置及实测性能如下表所示：

2.2.2 集群端口规划
2.2.2.1 单机主备集群

主备架构采用一主一备模式，业务请求全部连接主库（5238），备库通过实时同步保持数据一致。主库故障时需手动或通过dmwatcher将备库提升为主库。
2.2.2.2 DSC 共享存储集群

DSC采用共享存储架构，两个节点共享同一份ASM共享存储数据，节点间通过MAL网络进行全局锁管理和缓存同步。两个节点均为读写模式。
2.2.2.3 共享存储规划

2.2.3 数据库参数配置
2.2.3.1 DSC 初始化参数

2.2.3.2 CSS 自动拉起配置
DMDCR_PATH = /dev/dm/asm-dmdcr # DCR磁盘路径
DMDCR_SEQNO = 0 # 节点序号(0/1)
DMDCR_AUTO_OPEN_CHECK = 111 # 自动拉起开关
DMDCR_DB_RESTART_INTERVAL = 20 # 检测间隔(秒)
DMDCR_DB_STARTUP_CMD = DmServiceDSC0 start # 拉起命令
2.2.3.2关键路径

2.3 TPCC 配置
2.3.1 环境准备
2.3.1.1 安装 JDK
在用户root上：

执行命令：
yum install -y java-1.8.0-openjdk-devel

进行验证：
java -version
javac -version

2.3.1.2 安装 BenchmarkSQL
在用户root上：

从本地电脑上传 benchmarksql-5.0支持DM.zip 到服务器 /home/ 目录

解压

cd /home
unzip "benchmarksql-5.0支持DM.zip"


2.3.1.3 安装 Apache-Ant
在用户root上：

从本地电脑上传 apache-ant-1.9.16-bin.tar.gz 到服务器 /home/ 目录

解压

cd /home
tar -zxvf apache-ant-1.9.16-bin.tar.gz


2.3.1.4 安装 JDBC 驱动
在用户root上：
cd /home/benchmarksql-5.0
mkdir -p lib/dameng

cp /opt/dmdbms/drivers/jdbc/DmJdbcDriver8.jar lib/dameng/

2.3.1.5 编译 BenchmarkSQL
在用户root上：
cd /home/benchmarksql-5.0
chmod +x run/*.sh
/home/apache-ant-1.9.16/bin/ant

编译成功后显示：BUILD SUCCESSFUL
2.3.2 数据库端准备
在用户dmdba上：
disql sysdba/Zhangxinyu-0221@192.168.200.205:5236

创建表空间

create tablespace "BENCHMARKSQL1" datafile 'tpcc.dbf' size 1024 CACHE = "NORMAL";

创建用户

CREATE USER "BENCHMARKSQL" IDENTIFIED BY "Zhangxinyu-0221" DEFAULT TABLESPACE "BENCHMARKSQL1";
GRANT DBA TO BENCHMARKSQL;

创建测试表
2.3.3 配置文件 props.dm
在用户root上：
cd /home/benchmarksql-5.0/run
cp props.ora props.dm
vi props.dm

内容如下：
db=dameng
driver=dm.jdbc.driver.DmDriver
conn=jdbc:dm://DMDW
user=BENCHMARKSQL
password=Zhangxinyu-0221
warehouses=20
terminals=12
runTxnsPerTerminal=0
runMins=10
limitTxnsPerMin=0
newOrderWeight=45
paymentWeight=43
orderStatusWeight=4
deliveryWeight=4
stockLevelWeight=4
参数说明：

2.3.4 装载数据
在用户root上：
cd /home/benchmarksql-5.0/run
./runLoader.sh props.dm numWarehouses 20


数据装载只需执行一次，重复压测无需重新装载。
2.3.5 补充参数说明
2.3.5.1 BenchmarkSQL 测试参数

2.3.5.2 提取秒级波动数据
awk -F',' 'NR>1{sec=int($2/1000);t[sec]++
if($5=="NEW_ORDER")n[sec]++}
END{for(i=0;i<=600;i++)print i,(n[i]+0)60,(t[i]+0)60}'
my_result_xxx/data/result.csv > data_xxx
2.3.5.3 建表、装载、压测参数说明

2.4 单机主备集群 TPCC 测试
2.4.1 并发摸高测试
使用sed命令修改props.dm中的terminals参数，此处从12开始运行，接着运行50，后发现50的TPCC较12更差，故改并发数为20，继续修改至8。每轮运行10分钟，分别记录tpmC。
2.4.2 摸高测试结果


图 2-1 各并发水平波动曲线
补充：一开始做的是10仓5分钟的12、50、100的摸高，仓数有点少且运行时间较短，故做了上述的改进。之前的摸高对比图如下所示：

图 2-6 旧版摸高对比图
2.4.3 单节点 vs 双节点对比
对比单实例与主备双节点都开启两种场景下的性能差异。

图 2-7 单节点vs双节点对比
测试结果：备节点的存在对主节点性能存在一定影响，但差异在可接受范围内。
2.4.4 性能损耗根因分析
主备架构相比单实例产生显著性能损耗，主要由以下四方面因素导致：
（1）实时归档同步开销
主库每执行一个事务，均需生成REDO日志并通过MAL系统实时传输至备库。该过程在主库事务提交路径上增加了额外的网络发送和日志序列化开销，直接拉低了主库的事务处理速率。
（2）MAL系统通信开销
主备节点之间通过MAL进行心跳检测和数据传输。即使在本机环境（同一主机、同一网卡），TCP/IP协议栈的封装、解封装以及内核态与用户态的数据拷贝仍会产生不可忽视的协议处理开销。
（3）双写磁盘IO竞争
主库和备库均需将REDO日志写入本地磁盘。由于本次测试为单机主备部署，主库与备库共享同一块物理磁盘，两个实例同时执行顺序写操作，导致磁盘IO争抢严重，等待时间显著增加。
（4）守护进程轮询开销
dmwatcher和dmmonitor持续在后台执行状态轮询和心跳检测，占用一定的CPU和内存资源，进一步挤压了数据库实例可用的系统资源。
结论：本机主备部署模式下53.1%的性能损耗属于"以性能换取高可用"的典型代价。若采用双机主备部署（物理隔离、独立磁盘），因消除了磁盘IO竞争，性能损耗通常可降低至20%-30%。生产环境需在性能与高可用之间进行权衡：核心业务系统建议采用主备架构保障数据安全；以读操作为主的分析型系统可考虑单实例部署以获得更高吞吐量。
2.5 DSC 集群 TPCC 测试
2.5.1 DSC 单节点 TPCC 测试
12个并发全部连接DSC0（5236端口），DSC1同时运行但不处理TPCC请求。20仓库，运行10分钟。

DSC单节点存在严重掉零问题：第94_{103秒连续10秒跌零，第394}416秒连续22秒跌零。原因在于单节点连接时GLM锁管理或缓存同步导致连接阻塞。
2.5.2 DSC 双节点（6+6）TPCC 测试
开两个终端分别连接DSC0（6并发）和DSC1（6并发），合为12并发。运行10分钟。

DSC双节点6+6未实现线性性能提升，可能是因为节点间协调开销大于并行收益。
2.5.2.1 双节点连接配置

配置文件1：props_dsc0.sh（连DSC0，6并发）

conn=jdbc:dm://192.168.200.205:5236
terminals=6

配置文件2：props_dsc1.sh（连DSC1，6并发）

conn=jdbc:dm://192.168.200.205:5237
terminals=6
2.6 架构综合对比

图 2-8 三组性能对比

图 2-9 简洁版对比

三、sysbench 单机与主备性能测试
3.1 sysbench 测试概述
sysbench 是一款基于 Lua 脚本的多线程基准测试工具，广泛用于数据库性能测试，通过可扩展的脚本支持 OLTP 读写混合等多种负载模型，核心指标为 TPS（每秒事务数）与 QPS（每秒查询数）。
本次实验使用达梦适配版 sysbench 1.1.0（sysbench-master-dpi），通过 --db-driver=dm 参数连接达梦数据库，采用 oltp_read_write.lua 脚本进行读写混合事务压测。测试环境为 4 张表 × 5 万行，12 并发 × 300 秒，分别对单机实例（single01，5240）与主备集群（服务名 DMDW）进行对比测试，量化主备架构因实时归档同步带来的性能损耗。
3.2 实验环境

3.2.1 关键路径
本次实验关键路径如下：

3.2.2 端口规划
本次实验涉及的数据库端口规划如下：

3.3 工具部署
sysbench 采用达梦适配版（sysbench-master-dpi），自带达梦 DPI 驱动与依赖库。解压后置于 /opt/sysbench-master，进入 src/lua 目录运行。

cd /opt/sysbench-master/src/lua
./sysbench –version


3.4 服务名配置
为支持主备故障自动切换，配置达梦服务名文件 /etc/dm_svc.conf，将服务名 DMDW 指向主备两个节点，并设置 LOGIN_MODE=1（优先连接主库，故障自动切换）。
TIME_ZONE=(480)
LANGUAGE=(cn)
DMDW=(192.168.200.205:5238,192.168.200.205:5239)
[DMDW]
LOGIN_ENCRYPT=(0)
LOGIN_MODE=(1)
参数说明：


3.5 测试参数说明
sysbench 采用 读写混合事务，每次测试严格遵循建表装载、 压测、 清理三步闭环。本次主备与单机采用完全相同的参数以保证对比公平。

（1）主备集群测试流程：

建表装载数据

./sysbench oltp_read_write.lua --tables=4 --table-size=50000 --db-driver=dm --dm-db=DMDW --dm-user=SYSDBA --dm-password=Zhangxinyu-0221 --auto-inc=1 --threads=12 --time=300 --report-interval=10 prepare

正式压测

./sysbench oltp_read_write.lua --tables=4 --table-size=50000 --db-driver=dm --dm-db=DMDW --dm-user=SYSDBA --dm-password=Zhangxinyu-0221 --auto-inc=1 --threads=12 --time=300 --report-interval=10 run 2>&1 | tee /opt/sysbench_result/main_12_300.log

提取秒级波动数据

awk '/^[ [0-9]+s ]/{split($2,a,"s");print a[1],$7,$9,$14}' /opt/sysbench_result/main_12_300.log > /opt/sysbench_result/data_main_12_300.txt
cat /opt/sysbench_result/data_main_12_300.txt

清理测试表

./sysbench oltp_read_write.lua --tables=4 --table-size=50000 --db-driver=dm --dm-db=DMDW --dm-user=SYSDBA --dm-password=Zhangxinyu-0221 --auto-inc=1 --threads=12 --time=300 --report-interval=10 cleanup

（2）单机实例测试流程：

建表装载数据

./sysbench oltp_read_write.lua --tables=4 --table-size=50000 --db-driver=dm --dm-db=192.168.200.205:5240 --dm-user=SYSDBA --dm-password=Zhangxinyu-0221 --auto-inc=1 --threads=12 --time=300 --report-interval=10 prepare

正式压测

./sysbench oltp_read_write.lua --tables=4 --table-size=50000 --db-driver=dm --dm-db=192.168.200.205:5240 --dm-user=SYSDBA --dm-password=Zhangxinyu-0221 --auto-inc=1 --threads=12 --time=300 --report-interval=10 run 2>&1 | tee /opt/sysbench_result/main_single_12_300.log

提取秒级波动数据

awk '/^[ [0-9]+s ]/{split($2,a,"s");print a[1],$7,$9,$14}' /opt/sysbench_result/main_single_12_300.log > /opt/sysbench_result/data_single_12_300.txt cat /opt/sysbench_result/data_single_12_300.txt

cleanup：清理测试表

./sysbench oltp_read_write.lua --tables=4 --table-size=50000 --db-driver=dm --dm-db=192.168.200.205:5240 --dm-user=SYSDBA --dm-password=Zhangxinyu-0221 --auto-inc=1 --threads=12 --time=300 --report-interval=10 cleanup

3.6 主备集群测试

3.7 单机实例测试

3.8 主备 vs 单机对比分析
在完全相同的参数（4 表 × 5 万行 × 12 并发 × 300 秒）下，单机实例与主备集群的性能差异显著：

结论：主备架构因实时归档同步（每个事务需将 REDO 日志传输至备库），带来约 57% 的吞吐损耗，延迟亦显著上升。这是"以性能换取高可用"的典型代价，与 TPC-C 测试结论一致。生产环境中，核心业务系统建议采用主备架构保障数据安全；以读为主的分析型系统可考虑单机部署以获得更高吞吐。



图 3-1 单机 vs 主备 TPS 对比曲线

图 3-2 单机 vs 主备 95% 延迟对比曲线

图 3-3 单机 vs 主备关键指标柱状对比

四、JMeter 压测
4.1 JMeter 测试概述
Apache JMeter 是一款开源的 Java 压力测试工具，支持 HTTP、JDBC 等多种协议与数据库负载模拟，常用于接口与数据库性能测试。核心指标为吞吐量（req/s）、响应时间与错误率。
本次实验使用 JMeter 5.6.3 与达梦 JDBC 驱动，通过 JDBC Request 模拟真实业务负载，包括并发查询、DML（增删改）、8:1:1 读写混合与主备故障切换等场景，压测对象为 single01 单机实例（5240）与主备集群（服务名 DMDW，5238/5239），并通过并发摸高实验评估达梦数据库在高并发下的吞吐上限与拐点。
4.2 实验环境
本次 JMeter 压测的客户端部署于 Windows 11 主机，压测对象为本地虚拟机（192.168.200.205）上的达梦数据库，客户端与数据库服务器处于同一局域网，通过 JDBC 直连（jdbc:dm://192.168.200.205:5240），通过 MobaXterm 远程连接虚拟机进行管理和压测，使用 PyCharm 进行数据分析和图表生成。

4.2.1 关键路径
本次实验涉及的关键路径如下：

4.2.2 端口规划
本次实验涉及的数据库端口规划如下：

4.3 JMeter 并发查询与 DML 性能测试
4.3.1 环境准备
JMeter 5.6.3 部署于 Windows 主机，将达梦 JDBC 驱动 DmJdbcDriver8.jar 复制到 JMeter 的 lib 目录。压测客户端与达梦服务器处于同一局域网，通过 JDBC 驱动直连达梦数据库（192.168.200.205:5240）。
JMeter 通过 JDBC 驱动直连达梦数据库。



4.3.2 测试数据准备
在单机实例上创建业务表 jmtest 并装载 5 万行测试数据：
CREATE TABLE jmtest (id INT PRIMARY KEY, name VARCHAR(50), age INT, score DECIMAL(10,2), remark VARCHAR(200));
INSERT INTO jmtest (id, name, age, score, remark)
SELECT LEVEL, 'user_' || LEVEL, 20 + MOD(LEVEL,50), ROUND(DBMS_RANDOM.VALUE(50,100),2), 'remark_' || LEVEL
FROM DUAL CONNECT BY LEVEL <= 50000;
COMMIT;


4.3.3 JMeter 配置
JMeter 测试计划包含：线程组模拟并发用户、JDBC Connection Configuration 配置数据库连接池、JDBC Request 定义执行的 SQL、Simple Data Writer 记录结果数据。
（1）线程组配置

（2）JDBC 连接配置


4.3.4 并发查询测试
使用简单 SQL模拟并发查询场景，分别在 50、100、200 并发下各压测 60 秒。
SELECT * FROM jmtest WHERE id = ${__Random(1,50000)}




分析：并发从 50 增至 200，吞吐从 942 提升至 2570 req/s（约 2.7 倍），延迟缓慢上升，全程无错误，体现了达梦单机良好的并发扩展能力。




图 4-1 并发查询吞吐量 vs 并发数

图 4-2 并发查询延迟 vs 并发数

图 4-3 并发查询压测对比
4.3.5 DML 性能测试
分别对 INSERT、UPDATE、DELETE 三种 DML 操作在 50 并发下压测 60 秒。为规避主键冲突，INSERT 使用随机 id（100001~999999）。
INSERT：


UPDATE：


DELETE：




分析：三种 DML 吞吐排序为 INSERT > UPDATE > DELETE。DELETE 最慢（需定位、删除行并维护索引）。INSERT 存在 2.53% 的错误率，原因为随机 id 偶发主键冲突，属正常现象。





图 4-4 DML 吞吐量对比

图 4-5 DML 延迟对比

图 4-6 DML 压测运行
4.3.6 8:1:1 读写混合测试
参考达梦官方压测计划，模拟真实 OLTP 业务"读多写少"特征，在一个线程内按 8 个查询 : 1 个插入 : 1 个更新（共 10 个 JDBC Request）的顺序执行，50 并发压测 60 秒。


符合"读多写少"业务特征：读写混合时写操作占比约 20%，整体吞吐由读性能主导。



图 4-7 8:1:1 混合读写吞吐波动

图 4-8 各场景吞吐对比
4.4 主备故障自动切换演示
4.4.1 实验目的
验证达梦数据守护在 AUTO 模式下的自动故障切换能力：主库进程被杀后，备库自动提升为新主库，客户端通过服务名实现连接自动切换，业务仅短暂中断后恢复。
4.4.2 测试方法
（1）配置服务名 DMDW 指向主备节点（LOGIN_MODE=1 优先主库）；

（2）JMeter 50 并发通过服务名持续压测主库（时长 600 秒）；
（3）压测进行约 200 秒时，kill 主库 dmserver 进程（kill -9 主库 PID）；

（4）观察守护进程自动切换、备库提升、客户端自动重连的完整过程；



（5）通过 Simple Data Writer 记录每秒请求的成功率与耗时，绘制"低谷-恢复"曲线。
4.4.3 测试结果

实验结果：主库被 kill 后，守护进程约 10 秒内检测到故障，备库自动提升为新主库，原主库自动重启后降级为备库，主备角色对调。客户端通过服务名 DMDW 自动切换到新主库，压测仅中断约 2.2 秒（150 条请求失败）后完全恢复，数据无丢失。

图 4-9 故障切换成功率曲线（低谷-恢复）

图 4-10 故障切换每秒请求数曲线
4.5 JMeter 并发摸高实验
并发摸高实验通过不断增大 JMeter 并发线程数，测试达梦数据库在 8:1:1 读写混合负载（模拟真实 OLTP 业务）场景下的吞吐量上限，找出吞吐拐点与系统所能承受的最大并发数，验证数据库在高并发压力下的扩展能力与稳定性。
实验方法：在单机实例（single01，5240 端口）上，以 jmtest 表（5 万行）为测试对象，模拟真实 OLTP 业务 “读多写少”特征，在一个线程内按 8 个查询 : 1 个插入 : 1 个更新的顺序执行（8:1:1 读写混合）。并发数从 50 逐级提升至 600（50/100/150/200/250/300/350/400/500/600），每级压测 60 秒，记录各并发下的吞吐（req/s）、平均延迟、P95/P99 延迟与错误率，直至吞吐不再增长或出现明显错误，绘制吞吐-并发曲线并分析拐点。



测试结果：
并发从 50 增至 300，吞吐量近乎线性增长，系统处于良好扩展区间。当并发达到 300 时吞吐量达到峰值 2,832.9 req/s，此后继续增加并发，吞吐量不升反降或停滞，同时错误率也上升。这表明 300 并发为该负载模型下的最优并发点，系统性能拐点出现在 300 并发附近，继续加压不仅无法提升吞吐，反而带来延迟与错误的显著恶化。





图 4-11 吞吐量-并发数拐点曲线

图 4-12 延迟与错误率随并发变化曲线

五、总结与经验
5.1 实验总结
（1）在 12 个并发下，sysbench 压测单机实例每秒能处理约 2,110 个事务；JMeter 在 200 并发查询下，每秒能处理约 2,570 个请求，说明单机部署的性能很不错。然而主备比单机慢约一半：因为主备架构要实时把日志同步给备库，每个操作都多了一道同步的步骤，所以吞吐量下降了约 57%，延迟也翻倍。即数据更安全，但性能会打折扣。
（2）故障切换很靠谱：压测进行约 200 秒时把主库进程杀掉，守护进程约 10 秒内检测到故障，备库自动提升为新主库，原主库自动重启后降级为备库，主备角色对调。切换期间压测仅中断约 2.2 秒，客户端通过服务名自动连接到新主库，业务很快恢复正常，数据一条没丢，验证了达梦数据守护的自动切换能力。
（3）JMeter 8:1:1 混合负载下，每秒能处理约 825 个请求，说明达梦能比较好地支撑真实业务这种"读多写少"的负载。
（4）摸高实验找到了性能上限：并发从 50 加到 300 时，吞吐量一路涨到最高；但超过 300 并发后，吞吐量不再上涨，反而延迟变大、错误变多。所以 300 并发左右是这台达梦数据库的最佳工作点。
5.2 注意事项
（1）压测工具要和数据库驱动配套：sysbench 要用达梦适配版，JMeter 要把达梦的 JDBC 驱动 jar 放进它的 lib 目录，不然连不上数据库。
（2）主备压测要注意磁盘空间：主备同步时归档日志涨得很快（每分钟约 1.5GB），跑之前要留够磁盘空间，跑完及时清理。
（3）JMeter 插入数据要用随机 id：如果插入时 id 是写死的，第二次跑就会撞主键报错，用 ${__Random} 随机函数生成 id 就不会冲突。
（4）服务名配置是主备自动切换的关键：客户端要连主备集群，需要配好 dm_svc.conf 服务名文件，服务端和客户端两边都要配。
相关文章详见https://eco.dameng.com