达梦DM8数据库TPCC压测实战

虚拟机版本	VMwareWorkstation15
CPU	1核
内存	3G
利用体系版本	Kylin-V10-SP2
数据库版本	DM8_20231109_x86_kylin10
BenchmarkSQL	V4.1.1

目次
媒介
1.测试步调
1.1预备BenchmarkSQL
1.2初始化数据库
1.3设置参数
1.4预备测试数据
1.5实验测试
1.6查看测试报告
2.数据库性能优化
2.1性能分析
2.2优化方案
2.3优化结果
3.其他报错及解决方法

---

媒介

        本文使用的测试工具是BenchmarkSQL。BenchmarkSQL 是一个支持浩繁关系型数据库的基准测试工具，通过使用 BenchmarkSQL 对数据库进行 TPC-C 标准测试，即模拟多种事务处理：新订单、支付利用、订单状态查询、发货、库存状态查询等，从而获得终极的压测值。
        本文第1部门介绍达梦DM8数据库使用BenchmarkSQL测试的步调；第2部门实验优化DM8数据库，进步测试评分；第3部门记录了测试过程中碰到的问题及解决方法。
1.测试步调

1.1预备BenchmarkSQL

（1）安装JDK
本文使用的是BenchmarkSql V4.1.1，需要安装V1.7以上的JDK。
（2）解压

1. unzip benchmarksql-4.1.1.zip

复制代码

（3）设置驱动
将dm8的jdbc驱动放到lib目次下。
1.2初始化数据库

（1）建库
可以使用现有的数据库，也可以单独创建一个库用于测试。

1. ./dminit path=/dm8/data PORT_NUM=5238

复制代码

（2）新建用户
BENCHMARKSQL是测试专用用户，必须创建。

1. SQL> CREATE TABLESPACE TB_BENCHMARKSQL DATAFILE 'TB_BENCHMARKSQL01.dbf' SIZE 1024;
2. SQL> CREATE USER "BENCHMARKSQL"         IDENTIFIED BY "123456789" DEFAULT TABLESPACE "TB_BENCHMARKSQL";
3. SQL> GRANT DBA TO BENCHMARKSQL;

复制代码

1.3设置参数

设置文件props.dm，文件中必须设置的是：
1）数据库连接信息；
2）压测参数：warehouses、terminals、runMins。

1. cd ./benchmarksql-4.1.1/run
2. vi props.dm

复制代码

参数说明：
warehouses： 被测仓库数（数据规模）
terminals：  并发数（最大仓库数10倍）
runMins：    测试时间（分钟）
这3个参数可按照测试用例的要求设置，比方仓库数100，并发100，测试时间20分钟。
设置文件中下面有5个参数发起不要修改。
1.4预备测试数据

（1）建表

1. cd ./benchmarksql-4.1.1/run
2. chmod u+x *.sh
3. ./runSQL.sh props.dm sqlTableCreates

复制代码

（2）数据装载
注意：这里的仓库数与设置文件对应的参数值要一致

1. ./runLoader.sh props.dm numWarehouses 1

复制代码

（3）建索引

1. /runSQL.sh props.dm sqlIndexCreates

复制代码

（4）收集统计信息

1. SQL> CALL SYS.DBMS_STATS.GATHER_SCHEMA_STATS('BENCHMARKSQL',100);

复制代码

1.5实验测试

1. ./runBenchmark.sh props.dm

复制代码

1.6查看测试报告

前台实验的测试命令，可以直接看到测试结果，如1.5节截图。
还可以通过日志文件查看测试报告：

1. more ./log/benchmarksql.log

复制代码

测试报告解读：
tpmC=7479（本次测试得分）
tpmTOTAL=16694.04
tpmC：代表每分钟内体系处理的新订单个数
tpmTOTAL(TPS)：代表每分钟内体系处理的事务总数
Transaction Count：事务总数
参数关系如下：
tpmC = tpmTOTAL * newOrderWeight%
Transaction Count = tpmTOTAL * runMins


2.数据库性能优化

2.1性能分析

（1）查看缓冲池掷中率

排查结果：掷中率公道，不需要调解。
（2）查看文件分布

1. SQL> SELECT file_name from SYS.DBA_DATA_FILES ;
2. SQL> select path from SYS.V$RLOGFILE;

复制代码

排查结果：数据文件与重做日志文件在同一磁盘，有优化空间
（3）排查慢SQL

1. SQL> SELECT * FROM   V$LONG_EXEC_SQLS t;
2. SQL> SELECT * FROM  V$SYSTEM_LONG_EXEC_SQLS  t;

复制代码

排查结果：没有慢SQL
（4）按累计耗时排查SQL
累计耗时SQL排名

1. SELECT T.SQL_ID,sql_txt,sum(exec_time) exec_time_sum,avg(exec_time),count(*)
2. FROM V$SQL_STAT_HISTORY  t
3. group by T.SQL_ID,sql_txt
4. order by exec_time_sum desc;

复制代码

注：视图V$SQL_STAT_HISTORY中的exec_time之和要小于即是实际实验时间，缘故起因是V$SQL_STAT_HISTORY只生存10000条记录。
上图中前2条是体系SQL，可以忽略。反面是累计用时最多的7个SQL，我们分析下是否有优化空间：
查看SQL_ID=342实验计划

1. SELECT * from SYS.V$PLN_HISTORY t where t.SQL_ID=342;

复制代码

SQL:
UPDATE benchmarksql.warehouse SET w_ytd = w_ytd + ?  WHERE w_id = ?
实验计划：

分析：在实验计划中，SSEK2代表二级索引扫描、BLKUP2表现索引的二次扫描。如果将二级索引改为聚集索引，可以进步SQL的检索速度。

查看SQL_ID=347实验计划

1. SELECT * from SYS.V$PLN_HISTORY t where t.SQL_ID=347;

复制代码

SQL:
SELECT d_next_o_id, d_tax FROM benchmarksql.district WHERE d_id = ? AND d_w_id = ? FOR UPDATE
实验计划：

分析同上例，如果将二级索引改为聚集索引，可以进步SQL的检索速度。
用同样的方法，查看了累计耗时最多的7个SQL，都存在2级索引扫描的问题。
小结：
（1）缓冲区掷中率不需要优化
（2）磁盘IO性能有优化空间，考虑将日志文件、数据文件放到差别的磁盘
（3）没有实验时间凌驾1000ms的慢SQL
（4）频繁实验的SQL有优化空间
2.2优化方案

（1）磁盘性能优化
新建一块磁盘，挂载到/dmlog目次。
迁徙重做日志文件到新的磁盘：

1. SQL> ALTER DATABAE MOUNT;
2. SQL> ALTER DATABASE RENAME LOGFILE '/dm/data/DMDB/DMDB02.log' to '/dmlog/DMDB02.log';
3. SQL> ALTER DATABASE RENAME LOGFILE '/dm/data/DMDB/DMDB01.log' to '/dmlog/DMDB01.log';
4. SQL> ALTER DATABASE OPEN;

复制代码

（2）SQL优化方案
编辑创建索引的文件sqlIndexCreates，将主键改为聚集索引主键。

1. cp sqlIndexCreates sqlIndexCreates2
2. vi  sqlIndexCreates2

复制代码

2.3优化结果

删除测试表：
./runSQL.sh props.dm sqlTableDrops
重新测试：
实验1.4节、1.5节的命令，其中创建索引使用sqlIndexCreates2

优化后，tpmC由7479进步到了9354.82，性能进步25%。
3.其他报错及解决方法

以下是测试时碰到的2个报错。
（1）报错：多版本利用冲突
如下图

解决方法：多版本是对一张表修改时，并发量较大导致的。修改 dm.ini 文件里的参数：MVCC_RETRY_TIMES 数据调大，然后重启数据库。
（2）报错：当前光标不在结果集上
如下图：

解决方法：这个问题是props.dm文件中的warehouses值大于装载数据时的numWarehouses导致的。保证这两个值一致就可以了。
本文竣事！
20240905


免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。