虚拟机版本 | VMwareWorkstation15 |
CPU | 1核 |
内存 | 3G |
操作系统版本 | Kylin-V10-SP2 |
数据库版本 | DM8_20231109_x86_kylin10 |
BenchmarkSQL | V4.1.1 |
目录
前言
本文使用的测试工具是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)解压
unzip benchmarksql-4.1.1.zip
(3)配置驱动
将dm8的jdbc驱动放到lib目录下。
1.2初始化数据库
(1)建库
可以使用现有的数据库,也可以单独创建一个库用于测试。
./dminit path=/dm8/data PORT_NUM=5238
(2)新建用户
BENCHMARKSQL是测试专用用户,必须创建。
SQL> CREATE TABLESPACE TB_BENCHMARKSQL DATAFILE 'TB_BENCHMARKSQL01.dbf' SIZE 1024;
SQL> CREATE USER "BENCHMARKSQL" IDENTIFIED BY "123456789" DEFAULT TABLESPACE "TB_BENCHMARKSQL";
SQL> GRANT DBA TO BENCHMARKSQL;
1.3配置参数
配置文件props.dm,文件中必须配置的是:
1)数据库连接信息;
2)压测参数:warehouses、terminals、runMins。
cd ./benchmarksql-4.1.1/run
vi props.dm
参数说明:
warehouses: 被测仓库数(数据规模)
terminals: 并发数(最大仓库数10倍)
runMins: 测试时间(分钟)
这3个参数可按照测试用例的要求配置,例如仓库数100,并发100,测试时间20分钟。
配置文件中下面有5个参数建议不要修改。
1.4准备测试数据
(1)建表
cd ./benchmarksql-4.1.1/run
chmod u+x *.sh
./runSQL.sh props.dm sqlTableCreates
(2)数据装载
注意:这里的仓库数与配置文件对应的参数值要一致
./runLoader.sh props.dm numWarehouses 1
(3)建索引
/runSQL.sh props.dm sqlIndexCreates
(4)收集统计信息
SQL> CALL SYS.DBMS_STATS.GATHER_SCHEMA_STATS('BENCHMARKSQL',100);
1.5执行测试
./runBenchmark.sh props.dm
1.6查看测试报告
前台执行的测试命令,可以直接看到测试结果,如1.5节截图。
还可以通过日志文件查看测试报告:
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)查看文件分布
SQL> SELECT file_name from SYS.DBA_DATA_FILES ;
SQL> select path from SYS.V$RLOGFILE;
排查结果:数据文件与重做日志文件在同一磁盘,有优化空间
(3)排查慢SQL
SQL> SELECT * FROM V$LONG_EXEC_SQLS t;
SQL> SELECT * FROM V$SYSTEM_LONG_EXEC_SQLS t;
排查结果:没有慢SQL
(4)按累计耗时排查SQL
累计耗时SQL排名
SELECT T.SQL_ID,sql_txt,sum(exec_time) exec_time_sum,avg(exec_time),count(*)
FROM V$SQL_STAT_HISTORY t
group by T.SQL_ID,sql_txt
order by exec_time_sum desc;
注:视图V$SQL_STAT_HISTORY中的exec_time之和要小于等于实际执行时间,原因是V$SQL_STAT_HISTORY只保留10000条记录。
上图中前2条是系统SQL,可以忽略。后面是累计用时最多的7个SQL,我们分析下是否有优化空间:
查看SQL_ID=342执行计划
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执行计划
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目录。
迁移重做日志文件到新的磁盘:
SQL> ALTER DATABAE MOUNT;
SQL> ALTER DATABASE RENAME LOGFILE '/dm/data/DMDB/DMDB02.log' to '/dmlog/DMDB02.log';
SQL> ALTER DATABASE RENAME LOGFILE '/dm/data/DMDB/DMDB01.log' to '/dmlog/DMDB01.log';
SQL> ALTER DATABASE OPEN;
(2)SQL优化方案
编辑创建索引的文件sqlIndexCreates,将主键改为聚集索引主键。
cp sqlIndexCreates sqlIndexCreates2
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