使用BenchmarkSQL测试PostgreSQL
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 CLASSPATH
修改postgres.properties文件，即设置正确的数据库名和密码
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数目，然后进行测试。
Ø 标准测试模拟的程序环境
测试用到的模型是一个大型的批发销售公司，在地理分布的多个区域有业务，并且使用仓库管理。当业务扩展的时候，公司将添加新的仓库。每个仓库负责十个区域的供货，每个区域 3000 个客户服务，每个仓库维护 100000 种商品的库存纪录。如下图所示：
TPC-C 标准测试系统的数据库有 9 个表组成，他们之间的关系如下图所示：
其中W 代表仓库数,框中的数字表示该表将存放的记录条数，K代表1000，仓库数的调整在测试中能够体现数据库所能支持的数据规模的能力。每个 Warehouse 的数据量，其大小约为 76823.04KB，可以有小量的变化，因为测试过程中将会插入或删除现有记录。可以根据每个Warehouse的数据量，计算测试过程中的数据总量。
计算公式为：数据总量（KB）≈ Warehouse个数*76823.04KB
以10个Warehouse的数据量为例计算其数据总量大小约为：768230.4KB
Ø 标准测试模拟的事务处理
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
---------------------
二、测试前提
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文件中看到该软件的使用说明，下面用中文具体介绍一下它的使用方法。
三、测试步骤
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）；
参考资料：
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目录下，可以打开看是否有报错退出。
