码迷,mamicode.com
首页 > 其他好文 > 详细

tpcc使用说明

时间:2020-05-11 15:07:51      阅读:142      评论:0      收藏:0      [点我收藏+]

标签:4行   rman   his   tpc   详细   lib64   man   dtp   max   

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结果值(每分钟事务数,该值是第一次统计结果中的新订单事务数除以总耗时分钟数)

完毕!

tpcc使用说明

标签:4行   rman   his   tpc   详细   lib64   man   dtp   max   

原文地址:https://blog.51cto.com/4709096/2494171

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!