达梦数据库TPCC基准测试完整指南本文详细记录了达梦数据库相关集群的部署与测试过程包括环境准备、配置步骤、验证方法及踩坑记录。文章目录达梦数据库TPCC基准测试完整指南概述测试目标测试环境测试工具测试方法测试流程1. 删表2. 建表3. 装载数据4. 建索引5. 执行TPCC压测配置文件单节点性能测试不同缓存大小对比不同数据量对比不同CPU核数对比不同缓存大小2仓对比主备集群性能测试主备vs单节点性能对比主备集群不同数据量对比优化对比测试AutoPara优化添加索引优化测试结果汇总与分析完整测试结果汇总关键结论性能优化建议心得体会概述测试目标本次TPCC基准测试旨在全面评估达梦数据库在标准OLTP场景下的性能表现使用BenchmarkSQL 5.0工具通过多维度对比测试深入分析不同配置对数据库性能的影响为生产环境部署和性能优化提供参考依据。测试覆盖了以下维度单节点不同缓存大小对比、不同数据量对比、不同CPU核数对比、单节点与主备集群对比、以及AutoPara优化和索引优化的效果对比。测试环境测试工具BenchmarkSQL是一款开源的TPC-C基准测试工具支持多种数据库包括达梦数据库。它模拟真实的OLTP业务场景包含5种事务类型● 新订单New-Order占比约45%核心事务tpmC指标的统计对象。● 支付Payment占比约43%模拟支付操作。● 订单状态查询Order-Status占比约4%查询订单状态。● 发货Delivery占比约4%批量发货处理。● 库存查询Stock-Level占比约4%查询库存水平。核心性能指标● tpmC每分钟新订单事务数是TPC-C基准测试的核心性能指标行业通用。● tpmTOTAL每分钟总事务数包含所有5种事务约为tpmC的2~2.5倍。测试方法测试流程每次测试遵循标准的BenchmarkSQL测试流程步骤删表执行tableDrops.sql清理旧的测试数据。步骤建表执行tableCreates.sql创建9张测试表。步骤装载数据执行runLoader.sh按配置的仓库数生成测试数据。步骤建索引执行indexCreates.sql为测试表创建索引。步骤执行压测执行runBenchmark.sh运行指定时长的TPCC测试。1. 删表./runSQL.sh props.dm sql.common/tableDrops.sql2. 建表./runSQL.sh props.dm sql.common/tableCreates.sql3. 装载数据./runLoader.sh props.dm4. 建索引./runSQL.sh props.dm sql.common/indexCreates.sql5. 执行TPCC压测./runBenchmark.sh props.dm配置文件props.dm配置文件关键参数dbdmdriverdm.jdbc.driver.DmDriverconnjdbc:dm://DM_TPCC/DMuserBENCHMARKSQLpasswordZz200066!warehouses10loadWorkers10terminals10runMins5runTxnsPerTerminal0limitTxnsPerMin0terminalWarehouseFixedtrue每次测试运行约5分钟取稳定运行阶段的平均tpmC作为测试结果。单节点性能测试不同缓存大小对比测试了单节点下不同BUFFER缓存大小对性能的影响使用1仓1终端配置分别测试500MB缓存和1100MB缓存两种场景结果分析缓存从500MB增加到1100MBtpmC提升了约12.3%。由于1仓数据量较小约100MB两种配置下数据都能全部放入缓存因此性能提升幅度不大。缓存增加后更多的执行计划和数据字典可以放入内存减少了物理读和解析开销。图 1 一仓一终端500缓存图 2 一仓一终端1100缓存不同数据量对比测试了不同仓库数数据量对性能的影响使用2核1100MB缓存配置结果分析随着仓库数增加数据量增大性能急剧下降。2仓时tpmC下降了45.2%4仓时下降了76.9%。主要原因是2GB内存的机器1100MB缓存放不下全部数据导致大量物理读磁盘IO成为瓶颈。这验证了一个重要结论当数据量超过缓存容量时性能会急剧下降数据库从内存计算模式退化为磁盘IO模式。在生产环境中应尽量保证热数据全部放入内存缓存。图 3 二仓二终端1100缓存图 4 四仓四终端1100缓存不同CPU核数对比测试了不同CPU核数对性能的影响使用2仓2终端1100MB缓存配置结果分析核数从2增加到6性能反而略有下降。这说明在2仓2终端的场景下CPU不是瓶颈磁盘IO才是主要瓶颈。增加核数并不能提升性能因为大部分时间都在等IO。同时更多的核可能带来额外的调度开销导致性能轻微下降。这个结果提醒我们性能优化不能想当然不能盲目增加硬件。必须先找到真正的瓶颈然后针对性地优化。如果瓶颈在IO增加CPU是没有用的。图 5 二仓二终端6核心 1100缓存不同缓存大小2仓对比在2仓2终端场景下对比了1100MB缓存和2000MB缓存的性能结果分析缓存从1100MB增加到2000MB性能反而略有下降。这是因为2GB内存的机器缓存设得太大操作系统可用内存减少可能导致系统颠簸swap反而降低性能。缓存大小需要合理配置不是越大越好。主备集群性能测试主备vs单节点性能对比测试了主备集群与单节点的性能差异使用1仓1终端1100MB缓存配置结果分析在1仓1终端的低压力场景下主备集群与单节点性能几乎相同差异不到1%。这是因为低压力下实时归档同步的开销很小不会对性能产生明显影响。这说明在低负载场景下数据守护集群的性能代价非常小几乎可以忽略不计。图 6 主备一仓一终端1100缓存主备集群不同数据量对比测试了主备集群下不同数据量的性能表现结果分析与单节点类似数据量增加后主备集群性能也大幅下降。2仓2终端相比1仓1终端tpmC下降了约45.1%下降幅度与单节点基本一致说明瓶颈同样在磁盘IO。图 7 主备二仓二终端 1100缓存优化对比测试AutoPara优化测试了AutoPara自动并行查询优化功能对性能的影响结果分析AutoPara优化后性能反而下降了45.3%。这是因为TPCC场景主要是简单的点查和更新并行查询不仅没有帮助反而增加了并行调度的开销。AutoPara更适合复杂的OLAP查询场景对于OLTP场景反而可能产生负面影响。在使用任何优化功能之前都应该先测试验证不能想当然地认为优化功能一定能提升性能。图 8 autopara优化添加索引优化测试了添加索引对性能的影响这是本次测试中最显著的性能提升结果分析添加索引后tpmC从424.73飙升到3910.14提升了约9.2倍这充分说明了索引对数据库性能的重要性。TPCC场景中有大量的查询操作索引可以将全表扫描转化为索引查找大幅减少IO开销。在没有索引的情况下每次查询都要扫描全表IO开销巨大加上索引后直接通过索引定位数据IO量减少几个数量级。这也提醒我们在实际生产环境中合理的索引设计是性能优化的第一要务。数据库设计阶段的索引设计比事后调参要有效得多。图 9 一仓一终端索引测试结果汇总与分析完整测试结果汇总关键结论● 索引是性能优化的第一要务添加索引后tpmC提升了9.2倍这是所有优化手段中效果最显著的。合理的索引设计可以带来数量级的性能提升。● 缓存命中率决定性能上限当数据量超过缓存容量时性能急剧下降。1仓数据全缓存比4仓数据部分缓存性能高4倍以上。● CPU不是OLTP的主要瓶颈在IO瓶颈场景下增加CPU核数对性能没有帮助甚至略有下降。性能瓶颈主要在磁盘IO。● 缓存不是越大越好2GB内存的机器缓存设2000MB反而比1100MB性能差因为系统可用内存不足导致颠簸。● 主备集群性能开销视负载而定低压力下主备开销很小1%高压力下实时归档同步会消耗更多性能。● 并行查询不适合OLTPAutoPara并行查询优化在OLTP场景下反而降低性能更适合OLAP复杂查询。性能优化建议● 优先优化索引检查所有业务表的索引设计确保常用查询和更新条件都有对应的索引。这是成本最低、效果最好的优化手段。● 合理配置缓存根据数据量配置合适的BUFFER大小尽量让热数据全部放入内存减少物理IO。但也不要设得太大要给操作系统留足够内存。● 使用SSD存储如果数据量较大无法全部放入缓存建议使用SSD存储大幅提升IO性能。● 分库分表数据量非常大时可以考虑分库分表将数据分散到多个节点提升整体吞吐量。● 读写分离读多写少的场景可以使用读写分离集群将读请求分发到备库提升整体吞吐量。心得体会本次TPCC基准测试是一次非常有价值的实践不仅掌握了BenchmarkSQL工具的使用方法更重要的是对数据库性能优化有了更深刻的理解。最大的收获是对性能瓶颈的理解。最初以为CPU是瓶颈增加核数就能提升性能实际测试后发现IO才是主要瓶颈增加核数反而可能因为调度开销降低性能。这让我深刻体会到性能优化不能想当然必须通过实际测试找到真正的瓶颈然后针对性地优化。索引对性能的影响之大也超出了我的预期。添加索引后性能提升了9倍这充分说明了数据库设计阶段的重要性——合理的表结构和索引设计比事后调参有效得多。很多人一遇到性能问题就想着调参数、加硬件其实最应该先检查的是索引设计是否合理。AutoPara优化反而降低性能这个结果也很有启发。它告诉我们没有万能的优化手段任何优化功能都有其适用场景。OLAP的优化手段用到OLTP上可能适得其反。在使用任何新功能、新特性之前都应该先在测试环境验证效果。缓存大小不是越大越好这个结论也很重要。很多人以为缓存越大性能越好实际上缓存太大导致操作系统内存不足反而会降低性能。性能调优是一个平衡的艺术需要在各个组件之间找到最佳平衡点。总结一下这次测试的核心收获一是性能测试要用数据说话不能凭感觉二是优化要先找瓶颈不能盲目调参三是没有万能的优化方案要根据场景选择合适的优化手段。这些经验不仅适用于达梦数据库也适用于所有数据库系统的性能优化工作。项目配置数据库版本DM8主库IP10.0.0.100备库IP10.0.0.101压测客户端IP10.0.0.103服务器CPU2核部分测试6核服务器内存2GB客户端内存1.9GB测试用户BENCHMARKSQL数据库端口5236守护组名GRP1OGUID45331测试工具BenchmarkSQL 5.0测试场景tpmCtpmTOTAL性能提升单节点 1仓1终端 500MB缓存379.95822.50基准单节点 1仓1终端 1100MB缓存426.62948.4012.3%测试场景tpmCtpmTOTAL性能下降幅度1仓1终端426.62948.40基准2仓2终端233.88539.33-45.2%4仓4终端98.41233.28-76.9%测试场景tpmCtpmTOTAL性能差异2核 2仓2终端233.88539.33基准6核 2仓2终端226.33509.84-3.2%测试场景tpmCtpmTOTAL性能差异2仓2终端 1100MB缓存233.88539.33基准2仓2终端 2000MB缓存221.57506.49-5.3%测试场景tpmCtpmTOTAL性能差异单节点 1仓1终端426.62948.40基准主备 1仓1终端424.73953.25-0.4%测试场景tpmCtpmTOTAL性能下降主备 1仓1终端424.73953.25基准主备 2仓2终端233.05503.64-45.1%测试场景tpmCtpmTOTAL性能变化主备 1仓1终端 未优化424.73953.25基准主备 1仓1终端 AutoPara优化232.14533.22-45.3%测试场景tpmCtpmTOTAL性能提升主备 1仓1终端 未建索引424.73953.25基准主备 1仓1终端 添加索引3910.148753.34820.6%测试场景tpmCtpmTOTAL相对基准单节点 1仓1终端 500缓存379.95822.5089.1%单节点 1仓1终端 1100缓存426.62948.40100%基准单节点 2仓2终端 1100缓存233.88539.3354.8%单节点 2仓2终端 2000缓存221.57506.4951.9%单节点 2仓2终端 6核 1100缓存226.33509.8453.0%单节点 4仓4终端 1100缓存98.41233.2823.1%主备 1仓1终端 1100缓存424.73953.2599.6%主备 2仓2终端 1100缓存233.05503.6454.6%主备 1仓1终端 AutoPara优化232.14533.2254.4%主备 1仓1终端 添加索引3910.148753.34916.5% 达梦数据库TPCC基准测试完整指南
达梦数据库TPCC基准测试完整指南本文详细记录了达梦数据库相关集群的部署与测试过程包括环境准备、配置步骤、验证方法及踩坑记录。文章目录达梦数据库TPCC基准测试完整指南概述测试目标测试环境测试工具测试方法测试流程1. 删表2. 建表3. 装载数据4. 建索引5. 执行TPCC压测配置文件单节点性能测试不同缓存大小对比不同数据量对比不同CPU核数对比不同缓存大小2仓对比主备集群性能测试主备vs单节点性能对比主备集群不同数据量对比优化对比测试AutoPara优化添加索引优化测试结果汇总与分析完整测试结果汇总关键结论性能优化建议心得体会概述测试目标本次TPCC基准测试旨在全面评估达梦数据库在标准OLTP场景下的性能表现使用BenchmarkSQL 5.0工具通过多维度对比测试深入分析不同配置对数据库性能的影响为生产环境部署和性能优化提供参考依据。测试覆盖了以下维度单节点不同缓存大小对比、不同数据量对比、不同CPU核数对比、单节点与主备集群对比、以及AutoPara优化和索引优化的效果对比。测试环境测试工具BenchmarkSQL是一款开源的TPC-C基准测试工具支持多种数据库包括达梦数据库。它模拟真实的OLTP业务场景包含5种事务类型● 新订单New-Order占比约45%核心事务tpmC指标的统计对象。● 支付Payment占比约43%模拟支付操作。● 订单状态查询Order-Status占比约4%查询订单状态。● 发货Delivery占比约4%批量发货处理。● 库存查询Stock-Level占比约4%查询库存水平。核心性能指标● tpmC每分钟新订单事务数是TPC-C基准测试的核心性能指标行业通用。● tpmTOTAL每分钟总事务数包含所有5种事务约为tpmC的2~2.5倍。测试方法测试流程每次测试遵循标准的BenchmarkSQL测试流程步骤删表执行tableDrops.sql清理旧的测试数据。步骤建表执行tableCreates.sql创建9张测试表。步骤装载数据执行runLoader.sh按配置的仓库数生成测试数据。步骤建索引执行indexCreates.sql为测试表创建索引。步骤执行压测执行runBenchmark.sh运行指定时长的TPCC测试。1. 删表./runSQL.sh props.dm sql.common/tableDrops.sql2. 建表./runSQL.sh props.dm sql.common/tableCreates.sql3. 装载数据./runLoader.sh props.dm4. 建索引./runSQL.sh props.dm sql.common/indexCreates.sql5. 执行TPCC压测./runBenchmark.sh props.dm配置文件props.dm配置文件关键参数dbdmdriverdm.jdbc.driver.DmDriverconnjdbc:dm://DM_TPCC/DMuserBENCHMARKSQLpasswordZz200066!warehouses10loadWorkers10terminals10runMins5runTxnsPerTerminal0limitTxnsPerMin0terminalWarehouseFixedtrue每次测试运行约5分钟取稳定运行阶段的平均tpmC作为测试结果。单节点性能测试不同缓存大小对比测试了单节点下不同BUFFER缓存大小对性能的影响使用1仓1终端配置分别测试500MB缓存和1100MB缓存两种场景结果分析缓存从500MB增加到1100MBtpmC提升了约12.3%。由于1仓数据量较小约100MB两种配置下数据都能全部放入缓存因此性能提升幅度不大。缓存增加后更多的执行计划和数据字典可以放入内存减少了物理读和解析开销。图 1 一仓一终端500缓存图 2 一仓一终端1100缓存不同数据量对比测试了不同仓库数数据量对性能的影响使用2核1100MB缓存配置结果分析随着仓库数增加数据量增大性能急剧下降。2仓时tpmC下降了45.2%4仓时下降了76.9%。主要原因是2GB内存的机器1100MB缓存放不下全部数据导致大量物理读磁盘IO成为瓶颈。这验证了一个重要结论当数据量超过缓存容量时性能会急剧下降数据库从内存计算模式退化为磁盘IO模式。在生产环境中应尽量保证热数据全部放入内存缓存。图 3 二仓二终端1100缓存图 4 四仓四终端1100缓存不同CPU核数对比测试了不同CPU核数对性能的影响使用2仓2终端1100MB缓存配置结果分析核数从2增加到6性能反而略有下降。这说明在2仓2终端的场景下CPU不是瓶颈磁盘IO才是主要瓶颈。增加核数并不能提升性能因为大部分时间都在等IO。同时更多的核可能带来额外的调度开销导致性能轻微下降。这个结果提醒我们性能优化不能想当然不能盲目增加硬件。必须先找到真正的瓶颈然后针对性地优化。如果瓶颈在IO增加CPU是没有用的。图 5 二仓二终端6核心 1100缓存不同缓存大小2仓对比在2仓2终端场景下对比了1100MB缓存和2000MB缓存的性能结果分析缓存从1100MB增加到2000MB性能反而略有下降。这是因为2GB内存的机器缓存设得太大操作系统可用内存减少可能导致系统颠簸swap反而降低性能。缓存大小需要合理配置不是越大越好。主备集群性能测试主备vs单节点性能对比测试了主备集群与单节点的性能差异使用1仓1终端1100MB缓存配置结果分析在1仓1终端的低压力场景下主备集群与单节点性能几乎相同差异不到1%。这是因为低压力下实时归档同步的开销很小不会对性能产生明显影响。这说明在低负载场景下数据守护集群的性能代价非常小几乎可以忽略不计。图 6 主备一仓一终端1100缓存主备集群不同数据量对比测试了主备集群下不同数据量的性能表现结果分析与单节点类似数据量增加后主备集群性能也大幅下降。2仓2终端相比1仓1终端tpmC下降了约45.1%下降幅度与单节点基本一致说明瓶颈同样在磁盘IO。图 7 主备二仓二终端 1100缓存优化对比测试AutoPara优化测试了AutoPara自动并行查询优化功能对性能的影响结果分析AutoPara优化后性能反而下降了45.3%。这是因为TPCC场景主要是简单的点查和更新并行查询不仅没有帮助反而增加了并行调度的开销。AutoPara更适合复杂的OLAP查询场景对于OLTP场景反而可能产生负面影响。在使用任何优化功能之前都应该先测试验证不能想当然地认为优化功能一定能提升性能。图 8 autopara优化添加索引优化测试了添加索引对性能的影响这是本次测试中最显著的性能提升结果分析添加索引后tpmC从424.73飙升到3910.14提升了约9.2倍这充分说明了索引对数据库性能的重要性。TPCC场景中有大量的查询操作索引可以将全表扫描转化为索引查找大幅减少IO开销。在没有索引的情况下每次查询都要扫描全表IO开销巨大加上索引后直接通过索引定位数据IO量减少几个数量级。这也提醒我们在实际生产环境中合理的索引设计是性能优化的第一要务。数据库设计阶段的索引设计比事后调参要有效得多。图 9 一仓一终端索引测试结果汇总与分析完整测试结果汇总关键结论● 索引是性能优化的第一要务添加索引后tpmC提升了9.2倍这是所有优化手段中效果最显著的。合理的索引设计可以带来数量级的性能提升。● 缓存命中率决定性能上限当数据量超过缓存容量时性能急剧下降。1仓数据全缓存比4仓数据部分缓存性能高4倍以上。● CPU不是OLTP的主要瓶颈在IO瓶颈场景下增加CPU核数对性能没有帮助甚至略有下降。性能瓶颈主要在磁盘IO。● 缓存不是越大越好2GB内存的机器缓存设2000MB反而比1100MB性能差因为系统可用内存不足导致颠簸。● 主备集群性能开销视负载而定低压力下主备开销很小1%高压力下实时归档同步会消耗更多性能。● 并行查询不适合OLTPAutoPara并行查询优化在OLTP场景下反而降低性能更适合OLAP复杂查询。性能优化建议● 优先优化索引检查所有业务表的索引设计确保常用查询和更新条件都有对应的索引。这是成本最低、效果最好的优化手段。● 合理配置缓存根据数据量配置合适的BUFFER大小尽量让热数据全部放入内存减少物理IO。但也不要设得太大要给操作系统留足够内存。● 使用SSD存储如果数据量较大无法全部放入缓存建议使用SSD存储大幅提升IO性能。● 分库分表数据量非常大时可以考虑分库分表将数据分散到多个节点提升整体吞吐量。● 读写分离读多写少的场景可以使用读写分离集群将读请求分发到备库提升整体吞吐量。心得体会本次TPCC基准测试是一次非常有价值的实践不仅掌握了BenchmarkSQL工具的使用方法更重要的是对数据库性能优化有了更深刻的理解。最大的收获是对性能瓶颈的理解。最初以为CPU是瓶颈增加核数就能提升性能实际测试后发现IO才是主要瓶颈增加核数反而可能因为调度开销降低性能。这让我深刻体会到性能优化不能想当然必须通过实际测试找到真正的瓶颈然后针对性地优化。索引对性能的影响之大也超出了我的预期。添加索引后性能提升了9倍这充分说明了数据库设计阶段的重要性——合理的表结构和索引设计比事后调参有效得多。很多人一遇到性能问题就想着调参数、加硬件其实最应该先检查的是索引设计是否合理。AutoPara优化反而降低性能这个结果也很有启发。它告诉我们没有万能的优化手段任何优化功能都有其适用场景。OLAP的优化手段用到OLTP上可能适得其反。在使用任何新功能、新特性之前都应该先在测试环境验证效果。缓存大小不是越大越好这个结论也很重要。很多人以为缓存越大性能越好实际上缓存太大导致操作系统内存不足反而会降低性能。性能调优是一个平衡的艺术需要在各个组件之间找到最佳平衡点。总结一下这次测试的核心收获一是性能测试要用数据说话不能凭感觉二是优化要先找瓶颈不能盲目调参三是没有万能的优化方案要根据场景选择合适的优化手段。这些经验不仅适用于达梦数据库也适用于所有数据库系统的性能优化工作。项目配置数据库版本DM8主库IP10.0.0.100备库IP10.0.0.101压测客户端IP10.0.0.103服务器CPU2核部分测试6核服务器内存2GB客户端内存1.9GB测试用户BENCHMARKSQL数据库端口5236守护组名GRP1OGUID45331测试工具BenchmarkSQL 5.0测试场景tpmCtpmTOTAL性能提升单节点 1仓1终端 500MB缓存379.95822.50基准单节点 1仓1终端 1100MB缓存426.62948.4012.3%测试场景tpmCtpmTOTAL性能下降幅度1仓1终端426.62948.40基准2仓2终端233.88539.33-45.2%4仓4终端98.41233.28-76.9%测试场景tpmCtpmTOTAL性能差异2核 2仓2终端233.88539.33基准6核 2仓2终端226.33509.84-3.2%测试场景tpmCtpmTOTAL性能差异2仓2终端 1100MB缓存233.88539.33基准2仓2终端 2000MB缓存221.57506.49-5.3%测试场景tpmCtpmTOTAL性能差异单节点 1仓1终端426.62948.40基准主备 1仓1终端424.73953.25-0.4%测试场景tpmCtpmTOTAL性能下降主备 1仓1终端424.73953.25基准主备 2仓2终端233.05503.64-45.1%测试场景tpmCtpmTOTAL性能变化主备 1仓1终端 未优化424.73953.25基准主备 1仓1终端 AutoPara优化232.14533.22-45.3%测试场景tpmCtpmTOTAL性能提升主备 1仓1终端 未建索引424.73953.25基准主备 1仓1终端 添加索引3910.148753.34820.6%测试场景tpmCtpmTOTAL相对基准单节点 1仓1终端 500缓存379.95822.5089.1%单节点 1仓1终端 1100缓存426.62948.40100%基准单节点 2仓2终端 1100缓存233.88539.3354.8%单节点 2仓2终端 2000缓存221.57506.4951.9%单节点 2仓2终端 6核 1100缓存226.33509.8453.0%单节点 4仓4终端 1100缓存98.41233.2823.1%主备 1仓1终端 1100缓存424.73953.2599.6%主备 2仓2终端 1100缓存233.05503.6454.6%主备 1仓1终端 AutoPara优化232.14533.2254.4%主备 1仓1终端 添加索引3910.148753.34916.5%