tpcc-mysql使用手册_tpcc使用说明

tpcc使用说明

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

一、介绍

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

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

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

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

tpcc测试库数据比例图

和

tpcc测试库数据表关系图

二、编译安装

1、下载地址

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'

[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................................ -- 压测结束

[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 表；

[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

(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] *

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

完毕！