tpcc使用说明

Posted 2020-11-28

tpcc使用说明

说明：文章内容起源于网络并结合自己的实验而得；但参考的文章地址当时没记录下来，如果发现有侵权问题，请留言。

一、介绍

压力测试是指在mysql上线前，需要进行大量的压力测试，从而达到交付的标准。压力测试不仅可以测试MySQL服务的稳定性，还可以测试出MySQL和系统的瓶颈。

TPCC测试：Transaction Processing Performance Council，要熟练使用TPC是一系列事务处理和数据库基准测试的规范。其中TPC-C是针对OLTP的基准测试模型，一方面可以衡量数据库的性能，另一方面可以衡量硬件性价比，也是广泛应用并关注的一种测试模型。

TPC-C测试模型给基准测试提供了一种统一的测试标准，并非实际应用系统中的真实测试结果，但通过测试结果，可以大体观察出MySQL数据库服务稳定性、性能以及系统性能等一系列问题。TPC-C仅仅是一个测试模型，而在实际测试中，需要参考和使用一些测试工具，对系统和MySQL数据库进行压力测试、稳定性测试。

TPC-C模型是以一个在线零售业为例，设计的一种模型，具体架构图参考
tpcc测试库数据比例图

和
tpcc测试库数据表关系图

二、编译安装

1、下载地址

https://github.com/Percona-Lab/tpcc-mysql

2、修改程序，以实现对MGR的支持

如果是测试MGR模式，则需要手动修改与history表相关内容，因为该表没有主键，而MGR却要求表必须有主键：否则，可跳过。

# unzip tpcc-mysql-master.zip

1）在建表语句中，新增主键列：

# vim tpcc-mysql-master/create_table.sql 

大约在62行处为history表的建表语句；在其中添加建立主键id的语句：

create table history (
id bigint not null auto_increment,  -- 新增id自增列
h_c_id int,
h_c_d_id tinyint,
h_c_w_id smallint,
h_d_id tinyint,
h_w_id smallint,
h_date datetime,
h_amount decimal(6,2),
h_data varchar(24),
PRIMARY KEY (id) -- 新增主键(注意与上一行的逗号分隔)
) Engine=InnoDB;

2）修改INSERT语句

# vim tpcc-mysql-master/src/load.c

大约在234行处为history表的INSERT语句，修改为如下内容:

"INSERT INTO history values(null,?,?,?,?,?,?,?,?)",  48) ) goto Error_SqlCall_close; 

修改说明:
对主键列id在插入时新增null值，以便id自增；
将记录原INSERT语句字符数校验的数字从43改为48；

以上2不修改完成后可以继续，执行编译了。

3、解压编译

# cd tpcc-mysql-master/src/
# make  (没有make install)

执行成功后，在tpcc-mysql-master解压目录下生成了tpcc_load和tpcc_start命令

4、查看libmysqlclient.so.xx库文件

备注:
当前的版本的tpcc必须使用libmysqlclient.so.xx版本的mysql库文件。
mysql5.6为libmysqlclient.so.18
mysql5.7为libmysqlclient.so.20

设置方式有如下2种：
方式1：mysql5.7的libmysqlclient.so.20

# cat /etc/ld.so.conf
include ld.so.conf.d/*.conf

# echo "/usr/local/mysql-5.7.24/lib/" >> /etc/ld.so.conf

# cat /etc/ld.so.conf
include ld.so.conf.d/*.conf
/usr/local/mysql-5.7.24/lib/

# /sbin/ldconfig -v 

方式2：mysql5.6的libmysqlclient.so.18

# ls -l /usr/lib64/libmysqlclient.so*

如果不存在，则后面执行tpcc_load和tpcc_start命令时会报错。

将Mysql程序目录下lib目录中的libmysqlclient.so.18拷贝放入系统库并赋权限(也可在环境变量的PATH中指定该库文件地址)：

# mv libmysqlclient.so.18 /usr/lib64/
# chmod 777 /usr/lib64/libmysqlclient.so.18 

在测试完成后，删除该库文件

# rm /usr/lib64/libmysqlclient.so.18

三、加载测试数据

进入工作目录(解压后的目录)

# cd tpcc-mysql-master

1、在目标MySQL上创建测试数据库

mysqladmin -uroot -p -S /data/s1/mysql.sock create tpcc1000

2、创建表

mysql -uroot -p -S /data/s1/mysql.sock tpcc1000 < create_table.sql

tpcc创建了九张测试表：
客 户：customer 表
地 区：district 表
商 品：item 表
历史订单：history 表
新订单 ：new_orders 表
订单状态：order_line 表
订 单：orders 表
库存状态：stock 表
仓 库：warehouse 表

tpcc-mysql的业务逻辑及其相关的几个表作用如下：
New-Order==>新订单，一次完整的订单事务，几乎涉及到全部表
Payment ==>支付，主要对应 orders、history 表
Order-Status==>订单状态，主要对应 orders、order_line 表
Delivery ==>发货，主要对应 order_line 表
Stock-Level==>库存，主要对应 stock 表

3、对表添加外键

mysql -uroot -p -S /data/s1/mysql.sock tpcc1000 < add_fkey_idx.sql

4、载入测试数据

# ./tpcc_load --help
Usage: tpcc_load -h server_host -P port -d database_name -u mysql_user -p mysql_password -w warehouses -l part -m min_wh -n max_wh
* [part]: 1=ITEMS 2=WAREHOUSE 3=CUSTOMER 4=ORDERS

例如：创建5个仓库，加载全部表的测试数据

# ./tpcc_load -h 127.0.0.1 -P 3306 -d tpcc1000 -u root -p ‘123456‘  -w 5 

备注:
1）这个过程有点慢 ，1个warehouse对应10个地区，1地区对应3000的用户，10个仓库刚导入进去的大小约为1G；
2）仓数可根据需要来设置，总结网上资料所说，设置40-100个是对CPU的测试，400-1000个是对IO的测试，40以下无论事务多少，锁竞争情况也不太容易发生；
3）真实测试场景中，仓库数一般不建议少于100个，视服务器硬件配置而定，如果是配备了SSD或者PCIE SSD这种高IOPS设备的话，建议最少不低于1000个。

如果要并行加载测试数据，可以使用load.sh脚本。

四、执行测试

1、非MGR多主模式压测

./tpcc_start -h127.0.0.1 -P 3306 -dtpcc1000 -uroot -p ‘123456‘ -w 5 -c 32 -r 10 -l 30 -i 10 -f tpcc_mysql.log -t tpcc_mysql.rtx

-h：测试主机
-d：测试的数据库
-u：测试的用户
-p：测试用户的密码
-w：测试的warehouse数
-c：测试的连接线程数
-r：预热时间，warmup_time，以秒为单位，默认是10秒，目的是为了将数据加载到内存
-l：测试时间，默认为20秒
-i：report_interval指定生成报告的间隔时间
-f：report_file将测试中各项操作的记录输出到指定文件内保存
-t：trx_file输出更详细的操作信息到指定文件内保存

备注：
真实测试场景中，建议预热时间不小于5分钟，持续压测时长不小于30分钟，否则测试数据可能不具参考意义。

2、MGR多主模式压测

由于MGR在对大事务支持和事务冲突检测上的限制和不足，导致对MGR直接并行压测是不可能的。Oracle官方的Multi-Primary Mode测试是在每个结点上，
对不同的测试库进行压测，即这样可以避免了工具无法并行压测的问题，同时，这样也减少了冲突的可能性。切记，Multi-Primary Mode一定要避免热点数据冲突的场景。

例如MGR集群中有3个节点，分别为A、B、C；那么，压测时需要建立至少3个库；这样每个tpcc压测都使用1个线程来测试一个库，并且同时启动多个tpcc来测试。
可以这样测试：
A节点：

./tpcc_start -h188.188.0.68 -P3306 -uroot -p ‘123456‘ -d tpcc1 -w 5 -c 1 -r 10 -l 30 -i 10 -f tpcc_mysql.log -t tpcc_mysql.rtx
.....

B节点：

./tpcc_start -h188.188.0.69 -P3306 -uroot -p ‘123456‘ -d tpcc2 -w 5 -c 1 -r 10 -l 30 -i 10 -f tpcc_mysql.log -t tpcc_mysql.rtx
.....

C节点：

./tpcc_start -h188.188.0.70 -P3306 -uroot -p ‘123456‘ -d tpcc3 -w 5 -c 1 -r 10 -l 30 -i 10 -f tpcc_mysql.log -t tpcc_mysql.rtx
.....

不过对Multi-Primary Mode压测并不会有一个很好的结果，因为热点太过集中，会导致提交失败很多，或许反而会导致了性能的下降。

五、结果分析

[root@localhost tpcc-mysql-master]# ./tpcc_start -h127.0.0.1 -P24801 -dtpcc1000 -uroot -p ‘‘ -w 5 -c 32 -r 10 -l 30 -i 10 -f tpcc_mysql.log -t tpcc_mysql.rtx
***************************************
*** ###easy### TPC-C Load Generator ***
***************************************
option h with value ‘127.0.0.1‘
option P with value ‘24801‘
option d with value ‘tpcc1000‘
option u with value ‘root‘
option p with value ‘‘
option w with value ‘5‘
option c with value ‘32‘
option r with value ‘10‘
option l with value ‘30‘
option i with value ‘10‘
option f with value ‘tpcc_mysql.log‘
option t with value ‘tpcc_mysql.rtx‘
<Parameters>
     [server]: 127.0.0.1
     [port]: 24801
     [DBname]: tpcc1000
       [user]: root
       [pass]: 
  [warehouse]: 5
 [connection]: 32
     [rampup]: 10 (sec.)
    [measure]: 30 (sec.)

RAMP-UP TIME.(10 sec.)

MEASURING START.     -- 预热结束，开始进行压测 

-- 设置的每10秒钟输出一次压测数据
  10, trx: 1500, 95%: 204.109, 99%: 430.483, max_rt: 666.515, 1502|936.479, 150|225.372, 151|995.094, 151|650.192
  20, trx: 1349, 95%: 191.559, 99%: 458.275, max_rt: 659.284, 1342|842.605, 134|191.606, 136|981.992, 135|522.363
  30, trx: 1211, 95%: 209.746, 99%: 519.825, max_rt: 766.855, 1213|987.708, 122|142.544, 121|1085.795, 121|386.247

说明:分为6项，依次为操作时间(秒)、创建订单、订单支付、查询订单状态、物流发货以及查询库存仓储
10, ==>测试进行的时间(秒)
trx: 1500,  ==>在给定间隔期间执行的新订单交易数；它基本上是每个间隔内的吞吐量，该值越大越好。
95%: 204.109,==>每个给定间隔的95％的新订单交易响应时间，这里是204.109秒。
99%: 430.483,==>每个给定间隔的99％的新订单交易响应时间，这里是430.483秒。
max_rt: 666.515,==>每个给定间隔的新订单交易的最大响应时间，这里是666.515秒。
1502|936.479, 150|225.372, 151|995.094, 151|650.192==>是其他类型事务的吞吐量和最大响应时间，可以忽略。(订单支付、查询订单状态、物流发货以及查询库存仓储)

STOPPING THREADS................................    -- 压测结束

<Raw Results>
  [0] sc:0 lt:4060  rt:0  fl:0 avg_rt: 86.8 (5)
  [1] sc:1 lt:4056  rt:0  fl:0 avg_rt: 167.6 (5)
  [2] sc:345 lt:61  rt:0  fl:0 avg_rt: 8.6 (5)
  [3] sc:0 lt:408  rt:0  fl:0 avg_rt: 449.4 (80)
  [4] sc:15 lt:392  rt:0  fl:0 avg_rt: 132.6 (20)
 in 30 sec.

 -- 第一次结果统计说明
  [0] ==>New-Order，新订单业务成功(success,简写sc)次数，延迟(late,简写lt)次数，重试(retry,简写rt)次数，失败(failure,简写fl)次数；一次完整的订单事务，几乎涉及到全部表。
  [1] ==>Payment，支付业务统计，其他同上，主要对应 orders、history 表；
  [2] ==>Order-Status，订单状态统计，其他同上，主要对应 orders、order_line 表；
  [3] ==>Delivery，发货业务统计，其他同上，主要对应 order_line 表；
  [4] ==>Stock-Level，库存业务统计，其他同上，主要对应 stock 表；

<Raw Results2(sum ver.)>
  [0] sc:0  lt:4060  rt:0  fl:0 
  [1] sc:1  lt:4060  rt:0  fl:0 
  [2] sc:345  lt:61  rt:0  fl:0 
  [3] sc:0  lt:408  rt:0  fl:0 
  [4] sc:15  lt:392  rt:0  fl:0 

<Constraint Check> (all must be [OK])    -- 下面所有业务逻辑结果都必须为 OK 才行
 [transaction percentage]
        Payment: 43.45% (>=43.0%) [OK]  -- 支付成功次数(上述统计结果中 sc + lt)必须大于43.0%，否则结果为NG，而不是OK
   Order-Status: 4.35% (>= 4.0%) [OK]   -- 订单状态，其他同上
       Delivery: 4.37% (>= 4.0%) [OK]   -- 发货，其他同上
    Stock-Level: 4.36% (>= 4.0%) [OK]   -- 库存，其他同上
 [response time (at least 90% passed)]  -- 响应耗时指标必须超过90%通过才行
      New-Order: 0.00%  [NG] *      -- 下面几个响应耗时指标全部 未 通过
        Payment: 0.02%  [NG] *
   Order-Status: 84.98%  [NG] *
       Delivery: 0.00%  [NG] *
    Stock-Level: 3.69%  [NG] *

<TpmC>
                 8120.000 TpmC     -- TpmC结果值（每分钟事务数，该值是第一次统计结果中的新订单事务数除以总耗时分钟数）

完毕！