使用BenchmarkSQL测试PostgreSQL

时间 2019-11-19

标签使用 benchmarksql 测试 postgresql 栏目 Postgre SQL 繁體版

原文原文链接

BenchmarkSQL是一款经典的开源数据库测试工具，内嵌了TPCC测试脚本，能够对EnterpriseDB、PostgreSQL、MySQL、Oracle以及SQL Server等数据库直接进行测试，下面笔者就如何在Linux下使用这款测试工具测试PostgreSQL的性能来作一些简单介绍（操做系统为Fedora 12，PostgreSQL版本为8.0.22）。
首先，在Linux下安装JDK。由于BenchmarkSQL自己是使用Java语言编写的，因此若是在Linux系统下尚未安装JDK的话，咱们首先须要对其进行安装。
1）下载Linux Platform JDK（如jdk-6u20-linux-i586.bin）；
2）键入命令./jdk-6u20-linux-i586.bin运行安装程序，这时会有一段Sun的协议，敲几回Enter键，当询问是否赞成的时候敲Yes就能够了，以后程序会自行安装JDK并建立一个文件夹jdk1.6.0-20；
3）将安装后的文件夹移动到一个指定的地方，如mv jdk1.6.0-20 /usr/local，固然这一步不是必须的；
4）设置环境变量。环境变量的设置方法有多种如用export直接在shell下设置、修改文件.bashrc设置以及修改/etc/profile设置，咱们这里直接使用最后一种方法，虽然第二种方法比较受推崇。咱们在profile文件末尾直接添加以下内容：
JAVA_HOME=/usr/local/jdk1.6.0-20
PATH=$JAVA_HOME/bin:$PATH
CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar
export JAVA_HOME
export PATH
export CLASSPATHhtml

修改postgres.properties文件，即设置正确的数据库名和密码python

4)运行BenchmarkSQL进行测试。咱们首先进入到BenchmarkSQL-2.3.2/run的目录下，而后运行以下命令：
./runSQL.sh postgres.properties sqlTableCreates
此命令用于建立咱们进行TPCC测试所需的数据库表
./loadData.sh postgres.properties numWarehouses=10
此命令用于加载咱们进行TPCC测试所需的数据
./runSQL.sh postgres.properties sqlIndexCreates
此命令用于建立咱们进行TPCC测试所需的索引
./runBenchmark.sh postgres.properties
开始TPCC测试，这时会跳出一个对话框，用户能够根据本身的测试须要设定相关的warehouse数目和terminal数目，而后进行测试。linux

Ø 标准测试模拟的程序环境ios

测试用到的模型是一个大型的批发销售公司，在地理分布的多个区域有业务，而且使用仓库管理。当业务扩展的时候，公司将添加新的仓库。每一个仓库负责十个区域的供货，每一个区域 3000 个客户服务，每一个仓库维护 100000 种商品的库存纪录。以下图所示：sql

TPC-C 标准测试系统的数据库有 9 个表组成，他们之间的关系以下图所示：shell

其中W 表明仓库数,框中的数字表示该表将存放的记录条数，K表明1000，仓库数的调整在测试中可以体现数据库所能支持的数据规模的能力。每一个 Warehouse 的数据量，其大小约为 76823.04KB，能够有小量的变化，由于测试过程当中将会插入或删除现有记录。能够根据每一个Warehouse的数据量，计算测试过程当中的数据总量。数据库

计算公式为：数据总量（KB）≈ Warehouse个数*76823.04KBapache

以10个Warehouse的数据量为例计算其数据总量大小约为：768230.4KBwindows

Ø 标准测试模拟的事务处理bash

TPC-C 标准测试模拟了 5 种事务处理，经过这些事务处理来模拟真实的用户操做,事务分别为新订单（New-Order）、支付操做(Payment)、订单状态查询(Order-Status)、发货(Delivery)、库存状态查询(Stock-Level)。下面将对其执行的事务内容及特色进行详细介绍.

1．新订单（New-Order）

事务内容：对于任意一个客户端,从固定的仓库随机选取 5-15 件商品,建立新订单.其中 1%的订单要由假想的用户操做失败而回滚。

主要特色：中量级、读写频繁、要求响应快.

2．支付操做(Payment)

事务内容：对于任意一个客户端,从固定的仓库随机选取一个辖区及其内用

户,采用随机的金额支付一笔订单,并做相应历史纪录。

主要特色：轻量级，读写频繁，要求响应快

3．订单状态查询(Order-Status)

事务内容：对于任意一个客户端,从固定的仓库随机选取一个辖区及其内用户,读取其最后一条订单,显示订单内每件商品的状态。

主要特色：中量级，只读频率低，要求响应快

4．发货(Delivery)

事务内容：对于任意一个客户端,随机选取一个发货包,更新被处理订单的用户余额,并把该订单重新订单中删除.

主要特色：1-10 个批量，读写频率低，较宽松的响应时间

5．库存状态查询(Stock-Level)

事物内容：对于任意一个客户端,从固定的仓库和辖区随机选取最后 20 条订单,查看订单中全部的货物的库存,计算并显示全部库存低于随机生成域值的商品数量.

主要特色：重量级,只读频率低,较宽松的响应时间.

Ø 标准中事务处理须要知足的条件

TPC-C 标准测试要求事务处理必须知足下面的两组条件.

1. 事务处理要知足的时间及占有的比例

五种事务要知足的时间要求，包括键盘操做时间（Keying Time）,思考时间

因子(Think Time Distribution)以及 90%的响应时间（90th Percentile Response Time）限制。

2. 事务要知足的隔离级别

TPC-C 测试过程当中应该知足的隔离级别要求。要求只能高不能低。

T1到T5分别指五种事务：New-Order，Payment，Order-Status，Delivery，Stock-Level。

P0到P3分别指：脏写，脏读，非重复性读，幻影

Ø 测试指标

TPC-C测试的结果主要有两个指标，即流量指标（Throughput,简称tpmC)和性价比（Price/Performance,简称Price/tpmC)。

流量指标(Throughput,简称tpmC)：按照TPC组织的定义，流量指标描述了系统在执行支付操做、订单状态查询、发货和库存状态查询这4种交易的同时，每分钟能够处理多少个新订单交易。全部交易的响应时间必须满足TPC-C测试规范的要求，且各类交易数量所占的比例也应该知足TPC-C测试规范的要求。在这种状况下，流量指标值越大说明系统的联机事务处理能力越高。

性价比（Price/Performance,简称Price/tpmc)：即测试系统的总体价格与流量指标的比值，在得到相同的tpmC值的状况下，价格越低越好。

Ø TPC-C的测试工具

经常使用的开源TPC-C基准测试工具备BenchmarkSQL, dbt2-v0.23等等。

benchmarkSQL的安装部署

（1）.JDK1.7

（2）.apache ant

benchmarkSQL的配置文件解析:

第一个部分是JDBC链接信息。

第二个部分是场景设置，其中runTxnsPerTerminal是每分钟执行事务数，runMins是执行多少分钟，limitTxnsPerMin是每分钟执行的事务总数，而且这里时间的单位是分钟。场景执行的最低条件是第二项大于0。

第三个部分是TPCC中，五个事务执行的比例，总数等于100，一般不用修改。

典型配置：

Oracle配置须要修改的地方：

ü 每一个仓库要100M的空间1000个须要100G的存储表空间。

ü 设置ORACLE 批量提交参数：

SQL> alter system set commit_write='batch,nowait';

ü 使用强制软解析

SQL> alter system set cursor_sharing=force;

ü 使用O_DIRECT

SQL>alter system set filesystemio_options=directioscope=spfile;

SQL> alter system set disk_asynch_io=falsescope=spfile;

ü 修改最大链接数，打开游标数

SQL> alter system set processes=3000 scope=spfile;

SQL> ALTER SYSTEM SET open_cursors=900 SCOPE=BOTH;

SQL> alter system set session_cached_cursors=0scope=spfile;

ü 重启数据库

Ø Benchmarksql 操做<和howTO.txt不一样>：

在Oracle目标库建立了表空间和用户以后：

(1).runSQL.sh profile./sql.common/tableCreate.sql

(2).LoadSQL.shprofile

(3).runSQL.shprofile ./sql.common/indexCreate.sql

(4).runBenchmarkSQL.sh
---------------------

2、测试前提
1. 安装JDK。由于BenchmarkSQL自己是使用Java语言编写的，因此若是在Linux系统下尚未安装JDK的话，咱们首先须要对其进行安装；
2. 安装PostgreSQL数据库系统。俗话说巧妇难为无米之炊，测试以前确定须要有测试对象，本文是测试PG系统，故需安装有PG；
3. 安装BenchmarkSQL
可到http://sourceforge.net中搜索BenchmarkSQL便可下到，windows，linux版均有。我下载的是linux版的软件包BenchmarkSQL-2.3.3.zip，unzip解压后能够在README文件中看到该软件的使用说明，下面用中文具体介绍一下它的使用方法。

3、测试步骤
1. 启动待测试的数据库系统，这里即指启动PostgreSQL

2. 在BenchmarkSQL-2.3.3/run目录下找到postgres.properties配置文件，修改该文件以下：
driver=org.postgresql.Driver
conn=jdbc:postgresql://localhost:5432/test        #连接数据库地址
user=postgres      #连接数据库用户名
password=password    #密码
若是想测试其余数据库系统，则修改其余相应的配置文件便可，如oracle.properties等等。

3. 建立TPC-C基础表（即上篇博文中介绍的TPC-C模拟场景中9张表）
命令： runSQL.sh postgres.properties sqlTableCreates

4. 向数据库中导入指定大小的数据(参考资料2中此步有个小问题，多写一个等号)
命令：loadData.sh postgres.properties numWarehouses 10
numWarehouse指的是仓库数（具体含义见上篇博文），默认为1，导入9张表的数据大小大概70多M，
当 numWarehouse为10时，数据大小能够近似看成1GB数据。

5. 为基础表建立必要的索引
命令： runSQL.sh postgres.properties sqlIndexCreates

6. 运行runBenchmark.sh借助GUI程序测试数据库
命令：runBenchmark.sh postgres.properties
注意：不要忘记设置图形界面的仓库数时要与第4步中设置的数量相符；此外，测试的结果报告除了显示在图形界面有显示之外，还在run/reports目录下有备份，随时能够查阅。

注意：
1. 测试完后在界面下方会显示简要的测试结果，包括平均tpmC值（每分钟执行的事务数），当前tpmC值，内存使用状况等等；出结果之后尽可能记录下来，觉得以后若是乱点界面按钮的话，测试结果将会被重写（感受是一个bug）；

2.运行过程当中若是想要修改终端数等参数，最好关闭GUI界面，从新运行runBenchmark.bat

参考资料：
1.http://blog.sina.com.cn/s/blog_4485748101019wsh.html
2.http://blog.sina.com.cn/s/blog_48c95a190100j35g.html
3.http://www.docin.com/p-242425868.html

建立BenchmarkSQL配置文件：

切换到run路径下，复制一个props.pg文件，该文件是设置测试运行参数的文件，须要根据具体的测试要求进行修改：

[wieck@localhost benchmarksql] $ cd run

[wieck@localhost run] $ cp props.pg my_postgres.properties

[wieck@localhost run] $ vi my_postgres.properties

[wieck@localhost run] $

配置文件重要参数以下：

1）warehouse：

BenchmarkSQL数据库每一个warehouse大小大概是100MB，若是该参数设置为10，那整个数据库的大小大概在1000MB。建议将数据库的大小设置为服务器物理内存的2-5倍，若是服务器内存为16GB，那么warehouse设置建议在328～819之间。

2）terminals：

terminals指的是并发链接数，建议设置为服务器CPU总线程数的2-6倍。若是服务器为双核16线程（单核8线程），那么建议配置在32～96之间。

4.配置文件详解：

db=postgres //数据库类型，postgres表明咱们对PG数据库进行测试，不须要更改

driver=org.postgresql.Driver //驱动，不须要更改

conn=jdbc:postgresql://localhost:5432/postgres //PG数据库链接字符串，正常状况下，须要更改localhost为对应PG服务IP、5432位对应PG服务端口、postgres为对应测试数据库名

user=benchmarksql //数据库用户名，一般建议用默认，这就须要咱们提早在数据库中创建benchmarksql用户

password=PWbmsql //如上用户密码

warehouses=1 //仓库数量，数量根据实际服务器内存配置，配置方法见第3步

loadWorkers=4 //用于在数据库中初始化数据的加载进程数量，默认为4，实际使用过程当中能够根据实际状况调整，加载速度会随worker数量的增长而有所提高

terminals=1 //终端数，即并发客户端数量，一般设置为CPU线程总数的2～6倍

//每一个终端（terminal）运行的固定事务数量，例如：若是该值设置为10，意味着每一个terminal运行10个事务，若是有32个终端，那总体运行320个事务后，测试结束。该参数配置为非0值时，下面的runMins参数必须设置为0

runTxnsPerTerminal=10

//要测试的总体时间，单位为分钟，若是runMins设置为60，那么测试持续1小时候结束。该值设置为非0值时，runTxnsPerTerminal参数必须设置为0。这两个参数不能同时设置为正整数，若是设置其中一个，另外一个必须为0，主要区别是runMins定义时间长度来控制测试时间；runTxnsPerTerminal定义事务总数来控制时间。

runMins=0

//每分钟事务总数限制，该参数主要控制每分钟处理的事务数，事务数受terminals参数的影响，若是terminals数量大于limitTxnsPerMin值，意味着并发数大于每分钟事务总数，该参数会失效，想一想也是如此，若是有1000个并发同时发起，那每分钟事务数设置为300就没意义了，上来就是1000个并发，因此要让该参数有效，能够设置数量大于并发数，或者让其失效，测试过程当中目前采用的是默认300。

//测试过程当中的总体逻辑经过一个例子来讲明：假如limitTxnsPerMin参数使用默认300，termnals终端数量设置为150并发，实际会计算一个值A=limitTxnsPerMin/terminals=2（此处须要注意，A为int类型，若是terminals的值大于limitTxnsPerMin，获得的A值必然为0，为0时该参数失效），此处记住A=2；接下来，在整个测试运行过程当中，软件会记录一个事务的开始时间和结束时间，假设为B=2000毫秒；而后用60000（毫秒，表明1分钟）除以A获得一个值C=60000/2=30000，假如事务运行时间B<C，那么该事务执行完后，sleep C-B秒再开启下一个事务；假如B>C，意味着事务超过了预期时间，那么立刻进行下一个事务。在本例子中，每分钟300个事务，设置了150个并发，每分钟执行2个并发，每一个并发执行2秒钟完成，每一个并发sleep 28秒，这样能够保证一分钟有两个并发，反推回来总体并发数为300/分钟。

limitTxnsPerMin=300

//终端和仓库的绑定模式，设置为true时能够运行4.x兼容模式，意思为每一个终端都有一个固定的仓库。设置为false时能够均匀的使用数据库总体配置。TPCC规定每一个终端都必须有一个绑定的仓库，因此通常使用默认值true。

terminalWarehouseFixed=true

//下面五个值的总和必须等于100，默认值为：45, 43, 4, 4 & 4 ，与TPC-C测试定义的比例一致，实际操做过程当中，能够调整比重来适应各类场景。

newOrderWeight=45

paymentWeight=43

orderStatusWeight=4

deliveryWeight=4

stockLevelWeight=4

//测试数据生成目录，默认无需修改，默认生成在run目录下面，名字形如my_result_xxxx的文件夹。

resultDirectory=my_result_%tY-%tm-%td_%tH%tM%tS

//操做系统性能收集脚本，默认无需修改，须要操做系统具有有python环境

osCollectorScript=./misc/os_collector_linux.py

//操做系统收集操做间隔，默认为1秒

osCollectorInterval=1

//操做系统收集所对应的主机，若是对本机数据库进行测试，该参数保持注销便可，若是要对远程服务器进行测试，请填写用户名和主机名。

//osCollectorSSHAddr=user@dbhost

//操做系统中被收集服务器的网卡名称和磁盘名称，例如：使用ifconfig查看操做系统网卡名称，找到测试所走的网卡，名称为enp1s0f0，那么下面网卡名设置为net_enp1s0f0（net_前缀固定）；使用df -h查看数据库数据目录，名称为（/dev/sdb 33T 18T 16T 54% /hgdata），那么下面磁盘名设置为blk_sdb（blk_前缀固定）

osCollectorDevices=net_eth0 blk_sda

5. 建立数据库表并加载数据：

执行runDatabaseBuild.sh脚本，脚本后跟上面编辑好的配置文件，例如：

[wieck@localhost run]$ ./runDatabaseBuild.sh my_postgres.properties

# ------------------------------------------------------------

# Loading SQL file ./sql.common/tableCreates.sql

# ------------------------------------------------------------

create table bmsql_config (

cfg_name varchar(30) primary key,

cfg_value varchar(50)

);

create table bmsql_warehouse (

w_id integer not null,

w_ytd decimal(12,2),

[...]

Starting BenchmarkSQL LoadData

driver=org.postgresql.Driver

conn=jdbc:postgresql://localhost:5432/benchmarksql

user=benchmarksql

password=***********

warehouses=30

loadWorkers=10

fileLocation (not defined)

csvNullValue (not defined - using default 'NULL')

Worker 000: Loading ITEM

Worker 001: Loading Warehouse 1

Worker 002: Loading Warehouse 2

Worker 003: Loading Warehouse 3

[...]

Worker 000: Loading Warehouse 30 done

Worker 008: Loading Warehouse 29 done

# ------------------------------------------------------------

# Loading SQL file ./sql.common/indexCreates.sql

# ------------------------------------------------------------

alter table bmsql_warehouse add constraint bmsql_warehouse_pkey

primary key (w_id);

alter table bmsql_district add constraint bmsql_district_pkey

primary key (d_w_id, d_id);

[...]

vacuum analyze;

[wieck@localhost run]$

6. 运行测试：

执行脚本runBenchmark.sh，后面紧跟上面定义的配置文件做为参数，例如：

[wieck@localhost run]$ ./runBenchmark.sh my_postgres.properties

The benchmark should run for the number of configured concurrent

connections (terminals) and the duration or number of transactions.

The end result of the benchmark will be reported like this:

01:58:09,081 [Thread-1] INFO jTPCC : Term-00,

01:58:09,082 [Thread-1] INFO jTPCC : Term-00, Measured tpmC (NewOrders) = 179.55

01:58:09,082 [Thread-1] INFO jTPCC : Term-00, Measured tpmTOTAL = 329.17

01:58:09,082 [Thread-1] INFO jTPCC : Term-00, Session Start = 2016-05-25 01:58:07

01:58:09,082 [Thread-1] INFO jTPCC : Term-00, Session End = 2016-05-25 01:58:09

01:58:09,082 [Thread-1] INFO jTPCC : Term-00, Transaction Count = 10

至此整个测试流程完成。

7. 从新运行测试：

执行runDatabaseDestroy.sh脚本带配置文件能够将全部的数据和表都删除，而后再从新修改配置文件，从新运行build和benchmark脚本进行新一轮测试。

[wieck@localhost run]$ ./runDatabaseDestroy.sh my_postgres.properties

[wieck@localhost run]$ ./runDatabaseBuild.sh my_postgres.properties

8. 生成结果报告：

BenchmarkSQL测试会收集详细的性能指标，若是配置了操做系统参数收集，一样也会收集操做系统级别网卡和磁盘的性能指标，默认生成的数据在run/my_result_xx目录下。生成的报告，能够经过脚本文件generateReport.sh + my_result_xx生成带有图形的HTML文件。生成图形的脚本generateReport.sh要求操做系统环境中已经安装了R语言，R语言的安装在这里不赘述。

9.日志：

若是运行过程当中产生日志和错误，都会存储在run目录下，能够打开看是否有报错退出。