在kylin10 sp1下的sysbench压测dm全步骤+分析
前言
随着国产化软硬件生态的不断成熟，麒麟操作系统（Kylin OS）与达梦数据库（DM）的组合已成为政企行业数字化转型中的重要选择。作为衡量数据库性能的关键手段，压力测试能够直观反映系统在不同负载下的稳定性、吞吐量及资源消耗，为生产环境的配置优化、容量规划提供核心依据。
sysbench 作为一款开源的多线程性能测试工具，因其支持多种数据库驱动、可模拟真实 OLTP 场景而被广泛应用。本文聚焦Kylin10 SP1 操作系统，详细记录使用 sysbench 对达梦数据库进行全流程压测的操作步骤 —— 从环境准备、脚本编写、参数配置，到测试执行与数据采集，并结合压测结果（如吞吐量、延迟、系统资源占用）进行深度分析，最终总结达梦数据库在该环境下的性能表现及优化方向。
环境配置
- 操作系统：Kylin10 sp1
- 数据库：DM8——dm8_20250507_FTarm2000_kylin10_sp1_64.iso
- Jdk版本：JDK 1.8.0_272
- Sysbench版本：sysbench-master-dpi-20250328
1前期准备
首先我们需要将dm数据库跑起来，找到自己的dm数据库的bin目录下，输入./dmserver ./dbdata/test1/dm.ini，如果不想在前台跑的话，也可以修改命令在DmService到bin目录下进行cp service_template/DmService . ，然后输入vim DmService 并重新配置三个变量包含：DM_HOME、INT_PATH、DM_BIN_DIR并保存。
然后记得重命名服务名后再重启
mv DmService DmServicelsp
./DmServicelsp start
当看到ok即后台启动实例成功
2 配置sysbench并执行压测
2.1 解压安装sysbench
通过命令来解压sysbench文件。
unzip sysbench-master-dpi-20250328.zip
2.2 编译sysbench
执行autogen生成编译工具./autogen.sh，如果此处报错则环境存在问题
如果报错如下图则需要进行检查环境变量，输入env 进行检查，查看DM_HOME和LD_LIBRARY_PATH
export DM_HOME=/****/dmdbms/
export LD_LIBRARY_PATH=$DM_HOME/dependencies:$DM_HOME:$LD_LIBRARY_PATH
然后通过命令lscpu 来查看当前平台的环境，针对不同的操作系统使用不同的命令
| 操作系统 | 命令 |
|---|---|
| x86平台 | ./configure --without-mysql --with-dm |
| arm6平台 | ./configure --without-mysql --with-dm --build=aarch64-unknown-linux-gnu |
我这里是在arm6下的使用命令
./configure --without-mysql --with-dm --build=aarch64-unknown-linux-gnu
然后在源码路径下使用make 指令进行编译
在编译成功后，在src目录下生成可执行文件sysbench，将sysbench拷贝到src/lua目录下
cp sysbench ./lua
进入src/lua目录运行sysbench，出现如下input行则意味着sysbench成功安装并执行
./sysbench
2.3 准备数据与脚本
使用sysbench的写脚本准备测试数据，命令通过调用oltp_read_write.lua测试脚本，我这里在服务器中创建128张数据表，每张表预先插入25万行测试数据，总计生成3200万条测试记录；连接数据库时使用管理员账号SYSDBA和对应密码进行认证，特别禁用了自增主键功能（--auto-inc=0），并通过64个并发线程执行数据初始化工作，整个准备过程将持续180秒，期间每10秒输出一次数据准备进度报告。
./sysbench oltp_read_write.lua --tables=128 --table-size=250000 --db-driver=dm --dm-db=你的地址:端口号 --dm-user=SYSDBA --dm-password='数据库密码' --auto-inc=0 --threads=64 --time=180 --report-interval=10 prepare
需要在lua里面写一个.sh执行文件，这里我把我的执行文件放在下面，大家可以参考
然后进行执行测试，后台静默运行
nohup bash -c 'sh dm_perf_test_vmstat.sh 32 125;sh dm_perf_test_vmstat.sh 16 125;for rs in 64 32 16;do sh dm_perf_test_vmstat.sh 64 $rs;done;' &
3 压测结果解析
3.1 测试概况
本次测试通过控制 “线程数” 和 “表数量” 两个核心变量，形成 3组对比测试，具体组合如下：
| 测试序号 | 线程数 | 表数量 | 测试目的 |
|---|---|---|---|
| 1 | 64 | 128 | 高线程数 + 多表数量场景 |
| 2 | 64 | 64 | 高线程数 + 中表数量场景 |
| 3 | 64 | 32 | 高线程数 + 少表场景 |
| 4 | 64 | 16 | 高线程数 + 极少表场景 |
| 5 | 32 | 128 | 中线程数 + 多表数量场景 |
| 6 | 32 | 64 | 中线程数 + 中表数量场景 |
| 7 | 32 | 32 | 中线程数 + 少表场景 |
| 8 | 32 | 16 | 中线程数 + 极少表场景 |
- 测试配置：每张表 25 万行数据，测试类型为 OLTP 只读负载，每轮测试持续 180 秒，分 “监控关闭（ENABLE_MONITOR=0）” 和 “监控开启（ENABLE_MONITOR=1）” 两种状态，共执行 3 轮。
- 监控工具：通过
vmstat记录系统资源指标（CPU、内存、IO 等），采样间隔 1 秒。 - 日志文件：性能日志和系统监控日志。
3.2 核心性能指标对比
3.2.1 整体吞吐量（Events Per Second, eps）
吞吐量反映数据库处理请求的效率，数值越高性能越好。
| 场景 | 第 1 轮（eps） | 第 2 轮（eps） | 第 3 轮（eps） | 平均值（eps） |
|---|---|---|---|---|
| 64t_128tab | 1025.66 | 1070.33 | 947.08 | 1014.36 |
| 64t_64tab | 64.39(异常) | 1417.58 | 1399.95 | 960.64 |
| 64t_32tab | 1353.20 | 1336.39 | 430.42 | 1040.00 |
| 64t_16tab | 456.17 | 467.98 | 453.90 | 459.35 |
| 32t_64tab | 1380.49 | 1407.42 | 1416.61 | 1401.51 |
| 32t_32tab | 1480.96 | 1472.25 | 1441.50 | 1464.90 |
| 32t_16tab | 1188.57 | 1494.96 | 1486.41 | 1390.00 |
3.2.2 系统资源占用
| 场景 | 阶段 | CPU占用率 (%) | 内存占用 (GB) | 空闲CPU率(%) | 空闲内存(GB) | 缓存(GB) |
|---|---|---|---|---|---|---|
| us | sy | id | free | cache | ||
| 64t_64tab | 关闭监控 | 6.5 | 2.8 | 91.2 | 39 | 139.2 |
| 开启监控 | 15.6 | 7.6 | 65.9 | 37.9 | 138.7 | |
| 64t_32tab | 关闭监控 | 60 | 7.5 | 17.5 | 31 | 106.1 |
| 开启监控 | 45 | 20 | 35 | 25 | 106.2 | |
| 64t_16tab | 关闭监控 | 22 | 8 | 69 | 18.3 | 107.1 |
| 开启监控 | 15 | 5 | 80 | 18.7 | 107.2 | |
| 32t_64tab | 关闭监控 | 2.5 | 0.8 | 96.5 | 21.7 | 108.05 |
| 开启监控 | 3.5 | 1.2 | 94.5 | 20.75 | 108.15 | |
| 32t_32tab | 关闭监控 | 3.8 | 1.2 | 93.5 | 20.1 | 105.2 |
| 开启监控 | 5.2 | 2.1 | 87.2 | 19.8 | 103.5 | |
| 32t_16tab | 关闭监控 | 14.8 | 4.13 | 80.5 | 16.6 | 102.5 |
| 开启监控 | 24.5 | 4.93 | 69.6 | 16.2 | 102.8 |
3.2.3 核心发现
| 场景 | 核心瓶颈 | 监控开启资源变化 | 性能影响（TPS降幅） |
|---|---|---|---|
| 64t_64tab | CPU | sy↑129%，us↑140%，内存↓3% | 13% |
| 64t_32tab | CPU+IO | us↓25%，sy↑167%，IO写入量↑400% | 58% |
| 64t_16tab | IO | us↓32%，内存持平，IO等待↑500% | 29% |
| 32t_64tab | 无 | us↑40%，sy↑50%，变化微小 | 33% |
| 32t_32tab | CPU | us↑37%，sy↑75%，内存缓降 | 34% |
| 32t_16tab | CPU | us↑66%，sy↑19%，CPU空闲率↓13% | 31% |
3.3 场景分析
根据上面的表格我们可以进行分析：
- 64t_32tab死亡三角：
高并发(64t)+中表量(32)→ CPU过载 → 开启监控后sysCPU暴增 → TPS塌方(降58%)2. 最佳平衡点：
- 64线程选64表：us=6.5% → 开启监控us=15.6%（性能仅降13%）
- 32线程任意配置：保持us<25%的安全区
3.4 关键发现
- 监控的影响规律：监控开启普遍导致吞吐量下降，且不同线程数 - 表数量组合衰减幅度差异大。32t_32tab 场景衰减超 50%，64t_64tab 因首轮异常衰减看似小，实际正常状态也受影响；表数量与线程数适配性差的场景，监控开销相对占比高，性能更敏感。
- 异常轮次的共性：多场景出现单轮次吞吐量骤降（如 64t_64tab 首轮、64t_32tab 三轮 ），反映测试稳定性受初始环境、资源波动影响，需优化测试流程（增加预热、稳定资源 ），生产环境警惕此类突发波动。
- 线程数与表数量的适配性：存在 “适配则性能稳、不适配则波动大” 的规律。如 32t_32tab 监控关闭时性能稳定，64t_64tab 因线程数与表数量均为 64，首轮异常后性能也稳定；表数量过多或过少，易引发资源竞争或并行度不足，影响性能。
根据我们的发现我们可以进行分辨：
| 场景 | 是否启用监控 | 硬件最低要求 | 灾难熔断机制 |
|---|---|---|---|
| 64t+≤16表 | 谨慎开启 | CPU核数≥96, NVMe SSD日志 | sysCPU>15%时关闭 |
| 64t+32表 | ❌禁止 | CPU核数≥128, 独立监控节点 | us>40%触发降级 |
| 64t+64表 | ✅推荐 | CPU核数≥64 | 动态采样监控 |
| 32t任意配置 | ✅强制开启 | 基础配置 | 无需特殊熔断 |
4 结论与建议
本文基于 Kylin10 SP1 操作系统，通过 sysbench 工具完成了对达梦数据库的全流程压测，核心结论如下：
- 监控功能对数据库吞吐量有显著衰减，衰减幅度与线程数、表数量的适配性相关，适配性越差，衰减可能越明显。
- 测试初期易现异常，反映系统预热、资源初始化对数据准确性影响大，需规范测试流程。
- 线程数与表数量存在适配区间，合理组合可提升系统性能稳定性，过多或过少的表数量，或不匹配的线程数，易引发性能问题。
得出的建议如下：
- 测试优化：增加测试预热阶段（如空载运行 3 - 5 分钟 ），多次重复测试排除异常值；记录详细测试环境参数（CPU、内存、数据库配置等 ），便于异常分析。
- 监控策略：生产高峰期，对 32t_32tab 等监控敏感场景，关闭非必要监控；低峰期开启，或优化监控采集频率、指标，降低开销。优先监控关键业务指标，动态调整监控状态。
- 线程与表数量配置：业务追求高吞吐量、稳定性，优先测试线程数与表数量 1:1 或相近比例的组合（如 32t_32tab、64t_64tab ）；需高并发处理，适度增加线程数，同时调整表数量，平衡锁竞争与并行度，持续观测性能，动态优化配置 。
并且我们在进行优化的过程时可根据下图来进行优化：
联系客服
达梦在线服务平台社区用户管理规范
鄂ICP备18017926号-1