一、TPC-C测试前置环境准备

        通过VMware共享文件夹将各压缩包从宿主机Windows上传到Linux虚拟机上，即vmhgfs-fuse .host::/ /mnt/hgfs -o allow_other命令完成共享。

       将各压缩包从共享文件夹复制到/home的目录下进行解压操作：解压操作包括tar和unzip。最后将达梦数据库的jdbc驱动复制一份到benchmarksql的特定lib外部依赖库目录下让该工具能连接达梦数据库。

1、宿主机工具包准备

2、挂载虚拟机共享文件夹

在 Linux 终端执行挂载命令：

3、复制文件到系统工作目录

4、解压所有安装包，此时各个安装包都在/home目录下：

5、配置 JDK 环境变量

vi ~/.bash_profile：

6、创建目标目录并复制驱动

二、工具适配与集群参数设置

1、修改BenchmarkSQL工具源码适配达梦数据库

首先修改benchmarksql的src源码目录中数据库类型识别部分，增加达梦数据库类型确保后续编译和运行时能正常加载达梦驱动。

2、修改驱动加载脚本

vim /home/benchmarksql-5.0/run/funcs.sh：

3、Apache-ant编译BenchmarkSQL工具

进入benchmarksql根目录下执行ant目录进行编译，此时ant将benchmarksql源码编译成字节码文件并生成可执行JAR包存放在benchmarksql的/disk目录，此时benchmarksql能与达梦数据库完成连接并进行测试。

4、配置dm_svc.conf

定义服务名DMDW，包括主备两节点的IP和端口；设置连接模式LOGIN_MODE=(0)，即连接主库，若主库不可用不会自动连接备库，而是等主库恢复或新主库选举完成；并设置尝试次数300与重试间隔1s，开启自动重连。

5、编写benchmarksql中的配置文件props.dm

设置仓库数（warehouses）为10（受限于磁盘空间，未采用推荐的100仓）；终端数（terminals）为12；测试时长（runMins）为5分钟；事务权重中，新订单（NEW_ORDER）占比45%，支付（PAYMENT）占比43%，订单查询（ORDER_STATUS）4%，发货（DELIVERY）4%，库存水平（STOCK_LEVEL）4%。数据库连接使用服务名jdbc:dm://DMDW。

三、稳态性能压测

1、启动达梦主备集群服务

说明主备集群没有启动，需要进入达梦 bin 目录，依次启动主实例、备实例与集群监控服务：

cd /home/dmdba/dmdbms/bin

./DmServiceDM1 start

./DmServiceDM2 start

./DmMonitorServiceMonitor start

2、创建测试表空间与用户

集群启动完成后，使用 SYSDBA 账号登录集群，创建 TPCC 测试专用的表空间，再创建测试用户并将表空间设为默认表空间，最后授予 DBA 权限。

3、装载 TPCC 基准测试数据

4、执行稳态性能压测

5、查看压测结果输出

压测结束后，终端会输出最终的 tpmC、总事务数等核心性能指标，同时自动生成带时间戳的结果目录，保存测试过程的全部明细数据。

6、生成可视化测试报告

麒麟无法下载R语言，因此我把测试结果my_result_2026-07-28_150011传送到本地Windows系统进行绘图生成报告。

四、摸高测试

本测试基于达梦数据库创建了一张名为 TEST_GOODS 的商品信息表，该表包含 GOODS_ID（自增主键）、GOODS_NAME、PRICE、STOCK_NUM 和 CATEGORY_ID 五个字段。为满足JMeter并发性能测试的数据需求，已通过存储过程向表中批量插入了 10,000 条初始数据，所有记录的 PRICE、STOCK_NUM 和 CATEGORY_ID 字段在初始状态下均为固定值。

CREATE TABLE TEST_GOODS (     GOODS_ID      INT IDENTITY(1,1) PRIMARY KEY,  -- 自增主键     GOODS_NAME    VARCHAR(120),     PRICE         DECIMAL(12,2),     STOCK_NUM     INT,     CATEGORY_ID   INT );

1、将 JMeter 执行完成后的 .jtl 结果文件转换为 HTML 格式的可视化报告，便于查看各项性能指标（如 TPS、响应时间、错误率等）。

• 线程数为50：

TPS 稳定在 5000 左右，曲线平滑，系统运行最稳定。

• 线程数为70：

TPS 维持在 4800~5300 之间，但波动明显，有多个尖峰和谷底，说明系统在高负载下稳定性下降。

• 线程数为100：

TPS 从峰值约 5300 跌至 1000，系统在 100 并发下出现严重性能衰减。

2、对比结论

本次对达梦主备集群开展 JDBC 并发压力测试，分别设置 30、50、70、100 四档并发线程，每轮压测持续 4‑5min，验证主备集群在不同并发压力下吞吐量、响应时间及业务稳定性，观察主库业务处理能力，同时验证压力下主备节点运行状态。

并发线程	TPS （sec）	平均响应时间 (ms)	P99(ms)	错误率
30	1107.5	5	15	0.00%
50	4796.2	8	27	0.00%
70	4551.8	11	34	0.00%
100	4742.3	17	51	0.00%

随着并发增加，系统吞吐量并未提升（均在 5000 左右），反而稳定性下降（70 并发波动加剧，100 并发性能崩溃）。50 并发为最佳稳定运行负载，系统在 50 并发时达到性能上限，继续增加并发不会提升吞吐量，只会降低稳定性。

五、宕机测试

1、主库数据库实例故障（dmserver_error.jtl）

它的核心特征是：

• 数据库实例进程（dmserver）异常终止（被强制杀死或崩溃）。
• 守护进程（dmwatcher）依然存活，能够检测到实例异常。
• 集群会根据 INST_AUTO_RESTART 参数的值，决定是自动重启实例还是触发备库接管。

①监视器日志（11:13:24~11:30:40）

日志中明确记录了：

• 实例 DMSERVER 的角色为 STANDBY，发生故障（IMODE = STANDBY）。
• 守护进程自动重启该实例，约 12 秒后恢复正常。
• 实例 DMSERVER2 的角色始终为 PRIMARY，未发生切换。

②图表数据

表格显示在 11:13:00 ~ 11:17:30 期间，每秒事务数（TPS）始终为 1.000，没有波动或归零。这表明业务在持续运行，未出现服务中断。

③分析结论

• 业务未受任何影响：TPS 保持恒定，无下降或中断，主库持续提供服务。
• 备库自动恢复成功：守护进程在约 12 秒内完成实例重启并重新加入集群，同步恢复正常。

2、备库节点故障（dmwatcher_error.jtl）

先强制杀死守护进程（dmwatcher），再强制杀死数据库实例（dmserver）。

①监视器日志（13:23:53~13:23:55）

接管本身耗时约 1.2 秒，但总恢复时间较长（约 2.5 分钟），因为包含了 DW_ERROR_TIME 超时等待。

②图表数据

在13:24:00左右出现一个明显的失败波动峰值，随后失败请求持续存在，直到13:26:30之后才逐渐减少并消失。

③分析结论

• 业务未中断：在整个时间轴（13:24~13:32）上，绿色成功柱状条持续存在，未出现完全消失的时段，表明服务始终在对外响应，业务没有完全中断。
• 故障影响有限：红色失败柱状条集中在 13:25~13:27 之间出现，说明故障确实发生了，但失败与成功并存，集群在故障期间仍能处理部分请求。
• 自动恢复有效：红色柱状条在 13:27 之后逐渐减少并消失，绿色柱状条恢复至稳定水平，表明备库接管成功，集群已恢复正常服务能力。

3、备库数据库实例故障（dmserver2_error.jtl）

①监视器日志（13:50:26~13:50:41）

故障节点为DMSERVER2（角色为 STANDBY），守护进程在约 12 秒内自动完成了实例重启和集群重新加入，全程未发生切换，业务未受影响。

②图表数据

在整个 13:49:30 至 13:54:00 的时间窗口内，TPS 曲线始终稳定在 1.0，未出现任何下降、归零或波动。

③分析结论

本次测试验证了达梦数据守护集群在备库实例故障场景下的自愈能力——备库被守护进程自动拉起并重新加入集群，主库业务完全不受影响，集群高可用性符合预期。

4、主库节点故障（dmwatcher_error.jtl）

①监视器日志（14:14:40~14:14:42）

接管总耗时：从检测到故障（14:14:40.950）到接管完成（14:14:42.100），约 1.15 秒。

②图表数据

故障发生在 14:14:40，备库在约 1.15 秒内接管成功，但由于连接刷新和图表展示精度的原因，图表上绿色在 14:15:00 左右才开始恢复，14:18:00 完全恢复正常。接管本身的效率很高（1.15 秒），总业务影响约 3 分钟（含超时检测、接管、连接重建等完整过程）。

③分析结论

本次测试验证了达梦数据守护集群在主库节点故障场景下的自动接管能力——接管过程高效（约 1.15 秒），业务未完全中断，部分失败后快速恢复，高可用性符合预期。