达梦DM8数据库TPCC压测全流程解析与性能调优指南
1. 达梦DM8数据库TPCC压测环境搭建
第一次接触达梦DM8数据库的TPCC压测时，我踩了不少坑。记得当时为了赶项目进度，直接拿开发环境做测试，结果数据量一大就各种报错。后来老老实实按标准流程搭建测试环境，才发现原来性能可以差这么多。下面我就把完整的环境搭建经验分享给大家。
1.1 硬件与操作系统配置
虚拟机配置是压测的基础，这里我推荐使用VMware Workstation 16及以上版本。实测发现，15版本在长时间高负载运行时会出现内存泄漏问题。我的标准测试配置是：
- CPU：至少4核（TPCC测试对CPU要求较高）
- 内存：8GB起步（实测3GB内存跑100仓库会频繁swap）
- 磁盘：SSD固态硬盘，建议50GB以上空间
操作系统建议选择Kylin V10 SP2，这是与达梦DM8兼容性最好的国产系统。安装时要注意：
- 关闭selinux
- 调整swappiness值为10（默认60会导致频繁swap）
- 设置vm.dirty_ratio=20（降低脏页回写阈值）
# 永久修改内核参数 echo "vm.swappiness = 10" >> /etc/sysctl.conf echo "vm.dirty_ratio = 20" >> /etc/sysctl.conf sysctl -p1.2 数据库安装与初始化
达梦DM8的安装包建议使用20231109之后的版本，早期版本在TPCC测试中存在已知bug。安装完成后，初始化数据库时要特别注意两点：
- 字符集必须设置为UTF-8
- 页大小建议16KB（TPCC事务密集场景性能更好）
# 初始化命令示例 ./dminit path=/dm8/data PORT_NUM=5238 PAGE_SIZE=16 CHARSET=1初始化完成后，需要创建专用测试用户。这里有个细节容易被忽略——表空间初始大小。默认的100MB在TPCC测试中会导致频繁自动扩展，影响性能。
-- 创建专用表空间（建议1GB起步） CREATE TABLESPACE TB_BENCHMARKSQL DATAFILE 'TB_BENCHMARKSQL01.dbf' SIZE 1024; CREATE USER "BENCHMARKSQL" IDENTIFIED BY "123456789" DEFAULT TABLESPACE "TB_BENCHMARKSQL"; GRANT DBA TO BENCHMARKSQL;2. BenchmarkSQL工具配置详解
2.1 JDK与工具安装
BenchmarkSQL 4.1.1对JDK版本有严格要求，我实测发现：
- JDK1.8性能比1.7高15%左右
- OpenJDK比Oracle JDK稳定性更好
# 安装OpenJDK8 yum install -y java-1.8.0-openjdk # 解压BenchmarkSQL unzip benchmarksql-4.1.1.zip cd benchmarksql-4.1.1驱动配置是个关键点。达梦的JDBC驱动有多个版本，建议使用随DM8安装包提供的dmjdbc.jar。有个常见错误是把驱动放在lib/ext目录下，正确位置应该是lib/。
2.2 压测参数配置
props.dm文件中有三个核心参数直接影响测试结果：
- warehouses：数据规模，每个warehouse约100MB
- terminals：并发用户数，建议是warehouses的5-10倍
- runMins：测试时长，至少15分钟以上
# 典型配置示例（100仓库规模） db=dm driver=dm.jdbc.driver.DmDriver conn=jdbc:dm://localhost:5238 user=BENCHMARKSQL password=123456789 warehouses=100 terminals=50 runMins=30新手容易踩的坑：
- terminals设置过高会导致大量连接超时
- runMins太短（<10分钟）结果不准确
- 忘记注释掉默认的PostgreSQL配置项
3. 测试数据准备与执行
3.1 数据装载技巧
数据装载是TPCC测试中最耗时的环节。通过多次实测，我总结出几个提速技巧：
- 批量提交：修改runLoader.sh脚本，增加batchSize参数
- 并行装载：分多个终端同时运行loader
- 禁用约束：装载前临时禁用外键约束
# 修改后的装载命令示例 ./runLoader.sh props.dm numWarehouses 100 batchSize=1000装载完成后收集统计信息非常重要，但很多人忽略了采样率设置。对于TPCC这种数据分布均匀的场景，建议使用100%全量采集：
CALL SYS.DBMS_STATS.GATHER_SCHEMA_STATS('BENCHMARKSQL',100,'ALL',TRUE,'FOR ALL COLUMNS SIZE AUTO');3.2 测试执行与监控
执行测试时建议开启两个终端：
- 一个终端运行压测脚本
- 另一个终端监控数据库状态
# 监控关键指标 watch -n 1 "dmdbadmin -S -q \"select name,value from v\$sysstat where name in ('logical reads','physical reads','execute count')\""测试报告解读要关注三个核心指标：
- tpmC：每分钟处理的新订单数，是TPCC的核心指标
- 响应时间：90%线（Percentile 90）比平均值更有参考价值
- 错误率：超过1%就需要排查原因
4. 性能分析与调优实战
4.1 系统级性能分析
首先检查缓冲池命中率，理想值应在98%以上：
SELECT 1 - (phy_reads / (phy_reads + log_reads)) AS hit_ratio FROM ( SELECT sum(value) phy_reads FROM v$sysstat WHERE name = 'physical reads' ), ( SELECT sum(value) log_reads FROM v$sysstat WHERE name = 'logical reads' );如果命中率低，需要调整缓冲池大小：
-- 修改缓冲池大小（单位MB） ALTER SYSTEM SET 'MEMORY_POOL' = 2048 SCOPE=BOTH;4.2 SQL级优化案例
通过分析V$SQL_STAT_HISTORY视图，我发现最耗时的SQL是库存查询：
SELECT * FROM benchmarksql.stock WHERE s_w_id=? AND s_i_id=? FOR UPDATE;优化方案：
- 将二级索引改为聚集索引
- 增加覆盖索引
-- 创建优化后的索引 CREATE CLUSTER INDEX idx_stock_pk ON benchmarksql.stock(s_w_id, s_i_id);优化后，这个SQL的执行时间从平均15ms降到了3ms，整体tpmC提升了18%。
4.3 存储布局优化
默认安装会把数据文件和日志文件放在同一磁盘，这是性能瓶颈。我的优化步骤：
- 添加新磁盘并挂载到/dmlog
- 迁移重做日志文件
- 创建专用回滚表空间
-- 迁移日志文件 ALTER DATABASE MOUNT; ALTER DATABASE RENAME LOGFILE '/dm/data/DMDB/DMDB01.log' TO '/dmlog/DMDB01.log'; ALTER DATABASE OPEN; -- 创建专用回滚表空间 CREATE TABLESPACE UNDO_TBS DATAFILE '/dmlog/undo01.dbf' SIZE 1024; ALTER SYSTEM SET 'UNDO_TABLESPACE' = 'UNDO_TBS' SCOPE=BOTH;5. 常见问题排查指南
5.1 多版本冲突问题
当出现"多版本操作冲突"错误时，除了调整MVCC_RETRY_TIMES参数外，更重要的是：
- 检查事务隔离级别
- 优化热点数据访问模式
# dm.ini关键参数 MVCC_RETRY_TIMES=100 ISOLATION_LEVEL=READ_COMMITTED5.2 连接池耗尽
在高并发测试中经常遇到连接池耗尽的问题。解决方法：
- 增大数据库最大连接数
- 优化连接池配置
-- 修改最大连接数 ALTER SYSTEM SET 'MAX_SESSIONS' = 500 SCOPE=BOTH;在BenchmarkSQL的props.dm中增加连接池配置：
poolSize=50 poolTimeout=3005.3 数据不一致问题
测试过程中如果发现数据不一致，可以：
- 检查外键约束是否完整
- 验证触发器逻辑
- 使用DBMS_UTILITY包校验数据
-- 检查表数据完整性 BEGIN DBMS_UTILITY.VALIDATE('BENCHMARKSQL', 'WAREHOUSE'); END;经过这些优化，我的测试环境tpmC从最初的5000提升到了12000+。最关键的是要理解TPCC测试的每个环节都会影响最终结果，不能只盯着SQL优化。从硬件配置到参数调优，再到SQL改写，需要系统性地分析和改进。