TPC-C BenchMark压力测试PG

TPC-C BenchMark压力测试PG

最近在国家保密中心忙着做一些系统适配工作，一直没有更新，抽出时间总结了前段时间做的TPC-C的压测PG，今天跟大家分享一下。

背景:

先简单介绍一下TPC-C，TPC是一种基础程序的标准规范，而TPC-C是OLTP的基准程序，其模型采用C/S架构，针对的系统具有一下特性：

1.多事务并发

2.多会话访问

3.保证ACID

4.资源争夺明显

TPC-C通过TPM去衡量性价比，即每分钟的执行事务量，这个在之后的实验当中我们可以看到。

我们具体看下如何用TPC-C的BenchmarkSQL进行压力测试：

首先我们先获取几个重要的包：

1.BenchMark的安装包（这里选用的是benchmarksql-5.0）

2.Apache-ant-1.0.10.3-bin apache-ant是为了编译安装BenchSQL的包。

3.PG对应的jar包，在BenchMark里面有pg-9.3的包，如果你的PG版本过高的话，请在网上下载高版本的pg-jdbc包，因为我用的是UXDB，这里我就分享我们的jar包了。

下载地址：https://pan.baidu.com/s/1x5ffPQE07GuRLVNgVrdV9g

密码：bimy

解压BenchMark 和 Apache-ant包

配置apache-ant的环境变量

vi ~/.bash_profile

export APACH_HOME=/soft/tpcc/apache-ant-1.10.3

export PATH=$APACH_HOME/bin

source ~/.bash_profile

使用ANT编译BenchMark的包，需要用到BenchMark的build包，进入到BenchMark的目录，执行ant进行编译。

完成后我们对数据库进行配置

1.参数文件配置

修改数据库参数信息，数据库的参数配置合理才能让服务器的性能在TPCC报告当中有充分的显示。这里我不细讲参数配置，大家根据自己数据库的情况进行配置。

2.创建适配器支持

uxsql test -c "create extension postgres_adaptor;" 这里是UXDB专用的命令，我这里记录一下，为了方便我日后的工作，大家如果是PG，请忽略。

3.设置用户默认搜索路径

uxsql test -c "alter role uxdb set search_path='benchmarksql','public';"

这里的目的是将benchmarksql用户放在整个环境变量当中，然后在查询表的时候可以直接查到这个schema下对应的数据表。如果前面没有针对TPC-C测试创建新的用户的话，这里这步可以省略，在之后的建表过程当中默认的使用的public用户。

我这里说一下search_path的作用，search_path的作用就是环境变量，在查询的时候能够在某个用户下看到其他用户的表信息。

操作完数据库之后我们修改benchmark的脚本信息，我们在测试脚本信息的时候是受prop$.pg这个参数文件的影响。

这个是PG中专用的参数配置，驱动的写法，url的写法都是默认的，如果大家手头的环境是PG，这两个参数不用修改，PG的jar包默认放在了lib下。

user,password 是连接数据库的用户信息和密码信息。

warehouses 这里的意思就是数据仓库，这里直接表示markbench生成的数据表中数据量的大小。一般大小比例是如果这里的值是5000的话对应的数据大小大概在500g左右。

terminal 是指client的连接数量，这个数量越多就意味着我们的数据库以及服务器的负载就会增高，但是，这个值不是越高越好，在达到可承受的饱和值时，TPC-C的整体性能测试报告就会整体向下。

runTxnsPerTerminal是每分钟的执行事务数，runtime限制了执行的时间。

配置这两个参数的时候，如果runTxnsPerTerminal的不为0的话，那么runtime的值必须为0。反之，如果配置runtime的话，如果runtime不为0，则runTxnsPerTerminal一定要等于0。

limitTxnsPerMin=300 是限制每分钟总共执行的事务数。

至于下面的一些交易权重我们一般不修改

完成修改后下一步是建表:

使用runDatabaseBuild.sh

sh runDatabaseBuild.sh props.pg

这个脚本会创建一些测试表，而其中的数据量是受warehouse的大小去控制。

之后使用runBenchmark.sh进行测试

sh runBenchmark.sh props.pg

[uxdb@master run]$ ./runBenchmark.sh props.pg

11:09:32,633 [main] INFO jTPCC : Term-00,

11:09:32,687 [main] INFO jTPCC : Term-00, +-------------------------------------------------------------+

11:09:32,687 [main] INFO jTPCC : Term-00, BenchmarkSQL v5.0

11:09:32,687 [main] INFO jTPCC : Term-00, +-------------------------------------------------------------+

11:09:32,687 [main] INFO jTPCC : Term-00, (c) 2003, Raul Barbosa

11:09:32,687 [main] INFO jTPCC : Term-00, (c) 2004-2016, Denis Lussier

11:09:32,848 [main] INFO jTPCC : Term-00, (c) 2016, Jan Wieck

11:09:32,848 [main] INFO jTPCC : Term-00, +-------------------------------------------------------------+

11:09:32,848 [main] INFO jTPCC : Term-00,

11:09:32,848 [main] INFO jTPCC : Term-00, db=postgres

11:09:32,848 [main] INFO jTPCC : Term-00, conn=jdbc:uxdb://localhost:5432/uxdb

11:09:32,849 [main] INFO jTPCC : Term-00, user=uxdb

11:09:32,849 [main] INFO jTPCC : Term-00,

11:09:32,849 [main] INFO jTPCC : Term-00,warehouses=100

11:09:32,849 [main] INFO jTPCC : Term-00, terminals=50

11:09:32,850 [main] INFO jTPCC : Term-00, runMins=1

11:09:32,850 [main] INFO jTPCC : Term-00, limitTxnsPerMin=300

11:09:32,850 [main] INFO jTPCC : Term-00, terminalWarehouseFixed=true

11:09:32,850 [main] INFO jTPCC : Term-00,

11:09:32,850 [main] INFO jTPCC : Term-00, newOrderWeight=45

11:09:32,850 [main] INFO jTPCC : Term-00, paymentWeight=43

11:09:32,850 [main] INFO jTPCC : Term-00, orderStatusWeight=4

11:09:32,850 [main] INFO jTPCC : Term-00, deliveryWeight=4

11:09:32,850 [main] INFO jTPCC : Term-00, stockLevelWeight=4

11:09:32,850 [main] INFO jTPCC : Term-00,

11:09:32,850 [main] INFO jTPCC : Term-00, resultDirectory=my_result_%tY-%tm-%td_%tH%tM%tS

11:09:32,850 [main] INFO jTPCC : Term-00, osCollectorScript=./misc/os_collector_linux.py

11:09:32,850 [main] INFO jTPCC : Term-00,

11:09:33,740 [main] INFO jTPCC : Term-00, copied props.pg to my_result_2018-09-28_110933/run.properties

11:09:33,741 [main] INFO jTPCC : Term-00, created my_result_2018-09-28_110933/data/runInfo.csv for runID 5

11:09:33,741 [main] INFO jTPCC : Term-00, writing per transaction results to my_result_2018-09-28_110933/data/result.csv

11:09:33,752 [main] INFO jTPCC : Term-00, osCollectorScript=./misc/os_collector_linux.py

11:09:33,752 [main] INFO jTPCC : Term-00, osCollectorInterval=1

11:09:33,753 [main] INFO jTPCC : Term-00, osCollectorSSHAddr=null

11:09:33,753 [main] INFO jTPCC : Term-00, osCollectorDevices=net_ens33 blk_sda

11:09:39,525 [main] INFO jTPCC : Term-00,

11:09:49,836 [main] INFO jTPCC : Term-00, C value for C_LAST during load: 176

11:09:49,836 [main] INFO jTPCC : Term-00, C value for C_LAST this run: 63

11:09:49,836 [main] INFO jTPCC : Term-00,

Term-00, Running Average tpmTOTAL: 0.00 Current tpmTOTAL: 0 Memory Usage: 4MB Term-00, Running Average tpmTOTAL: 59.58 Current tpmTOTAL: 456 Mem11:12:13,942 [Thread-5] INFO jTPCC : Term-00,

11:12:13,942 [Thread-5] INFO jTPCC : Term-00,

11:12:13,942 [Thread-5] INFO jTPCC :Term-00, Measured tpmC (NewOrders) = 28.56

11:12:13,942 [Thread-5] INFO jTPCC :Term-00, Measured tpmTOTAL = 59.58

11:12:13,942 [Thread-5] INFO jTPCC : Term-00, Session Start = 2018-09-28 11:11:00

11:12:13,942 [Thread-5] INFO jTPCC : Term-00, Session End = 2018-09-28 11:12:13

11:12:13,942 [Thread-5] INFO jTPCC : Term-00,Transaction Count = 72

这里测试的性能结果会在输出中显示

tpmC(NewOrders) 这里是指每分钟新增的交易量，这里的值是tpmTOTAL的一半的原因是neworderWeight最大是45%，即新增交易量的比重最大是45%，所以这里显示的值将会tpmTOTAL的一半。

tpmTOTAL 是每分钟执行的事务数，这里的值是直接证明当前环境的事务之性能力。

session start / session end 是测试时间，这个时间根据大家的测试标准去限定。

TransactionCount是单位时间内总共执行的事务数。

在测试之后我们可以查看服务器的压力情况去调整测试的参数，在执行完一次测试之后，会在run目录下生成一个日期目录：

这个目录是记录测试结果的目录。

这些文件都是CSV文件，我们将他们从服务器中拖出来，使用excell打开

blk_sda.csv：反映了sda磁盘的io情况

net_ens33.csv：反映了ens33网卡的延迟情况

result.csv：反映了在测试这段时间当中执行的解析时间，等待时间，所执行的事务消耗的类别

runinfo.csv：反映了压力测试的限定参数，其中包括驱动器，开始时间，warehouse加载数量，每分钟最大事务量等，其实就是props.pg参数。

sys_info.csv：反映了系统的CPU压力情况。

其实在测试当中，我习惯性的打开vmstat并行检测服务器的压力情况，这样有助于我们去检测测试是不是让服务器达到了极限的情况，从而有助于我们更好的评估性能。

THAT'S ALL

BY CUI PEACE!!!!