DB性能测试-常用3套件-手把手一步一步跑tpcc

Posted on In , Views: Symbols count in article: 2.9k Reading time ≈ 11 mins.
性能测试 -- DB性能测试-常用3套件-手把手一步一步跑tpcc

Abstract

把过去的写的一篇笔记分享一下， 数据库最常用的测试三套件， sysbench – oltp 测试， tpch – olap 测试， tpcc – 事务性能测试。
本文手把手 一步一步 run tpcc

整个过程， 分为

  • 介绍
  • 准备工作
  • 编译
  • 测试
  • 疑难杂症

介绍

http://www.tpc.org/tpcc/
TPCC有不同的运行方式，用来测试数据库的压力工具，模拟一个电商的业务，主要的业务有新增订单，库存查询，发货，支付等模块的测试。 详情可以参考 https://github.com/domino-succ/tpcc-hbase/wiki/中文-TPC-C简介

模型简介

在测试开始前，TPC-C Benchmark规定了数据库的初始状态，也就是数据库中数据生成的规则，其中ITEM表中固定包含10万种商品，仓库的数量可进行调整，假设WAREHOUSE表中有W条记录，那么：

  • STOCK表中应有W×10万条记录(每个仓库对应10万种商品的库存数据)；
  • DISTRICT表中应有W×10条记录(每个仓库为10个地区提供服务)；
  • CUSTOMER表中应有W×10×3000条记录(每个地区有3000个客户)；
  • HISTORY表中应有W×10×3000条记录(每个客户一条交易历史)；
  • ORDER表中应有W×10×3000条记录(每个地区3000个订单)，并且最后生成的900个订单被添加到NEW-ORDER表中，每个订单随机生成5~15条ORDER-LINE记录。

在测试过程中，每一个地区（DISTRICT）都有一个对应的终端（Terminal），模拟为用户提供服务。在每个终端的生命周期内，要循环往复地执行各类事务，每个事务的流程如图所示，当终端执行完一个事务的周期后，就进入下一个事务的周期，如下图所示。

客户下单后，包含若干个订单明细（ORDER-LINE）的订单（ORDER）被生成，并被加入新订单（NEW-ORDER）列表。
客户对订单支付还会产生交易历史（HISTORY）。
每个订单(ORDER) 平均包含10条订单项(ORDER-LINE), 其中1% 需要从远程仓库中获取.
这些就是TPC-C模型中的9个数据表。其中，仓库的数量W可以根据系统的实际情况进行调整，以使系统性能测试结果达到最佳。

Metrics

TPCC用tpmC值（Transactions per Minute）来衡量系统最大有效吞吐量. 其中Transactions以NewOrder Transaction为准，即最终衡量单位为每分钟处理的订单数。

事务类型

该benchmark包含5类事务

  • NewOrder: 新订单的生成从某一仓库随机选取5-15件商品, 创建新订单. 其中1%的事务需要回滚(即err). 一般来说新订单请求不可能超出全部事务请求的45% |
  • Payment : 订单付款更新客户账户余额, 反映其支付情况. 占比 43%
  • OrderStatus : 最近订单查询 随机显示一个用户显示其最有益条订单, 显示该订单内的每个商品状态. 占比4%
  • Delivery  : 配送, 模拟批处理交易更新该订单用户的余额, 把发货单从neworder中删除. 占比4%
  • StockLevel  : 库存缺货状态分析 , 占比4%

要求

然后，终端模拟用户输入事务所需的参数，并等待一个输入时间（Keying Time）；等待结束后，事务执行正式开始，执行结束后记录事务的实际执行时间（txnRT），TPC-C对每类事务的执行时间都有一个最低要求，分别是：

  • 至少90%的NewOrder事务执行时间要低于5秒，
  • 至少90%的Payment事务执行时间要低于5秒，
  • 至少90%的OrderStatus事务执行时间要低于5秒，
  • 至少90%的Payment事务执行时间要低于5秒，
  • 至少90%的StockLevel事务执行时间要低于20秒；

最后，终端模拟用户对结果的查看以及思考，等待一个思考时间（Thinking Time）；在思考时间结束后，进入下一个事务周期。 在整个测试过程结束后，用处理过的新订单事务总数量除以整个测试运行的分钟数并取整，就得到了tpmC的值。

测试工具调研

TPC-C测试常用的测试工具包括tpcc-mysql，benchmark-sql，Hammer DB，DBT2，sqlbench。这些工具对TPC-C标准的支持程度不尽相同。经过调研发现从DBT2改进来的开源的sqlbench工具是最接近标准要求的测试工具。因此我们首先对比不同工具对标准的支持情况，然后介绍使用sqlbench进行TPC-C测试的步骤。

tpcc-mysql简介

TPCC-MYSQL 是percona基于TPC-C(下面简写成TPCC)衍生出来的产品，专用于MySQL基准测试。用来测试数据库的压力工具，模拟一个电商的业务，主要的业务有新增订单，库存查询，发货，支付等模块的测试。使用说明明文档（https://www.percona.com/blog/2013/07/01/tpcc-mysql-simple-usage-steps-and-how-to-build-graphs-with-gnuplot/）。

benchmark-sql简介

benchmark-sql是java语言实现TPCC工具，使用JDBC接口，支持Oracle、PostgreSQL、firebird和MySQL。

HammerDB简介

HammerDB是Tcl语言实现TPCC/TPCH工具，使用存储过程和Tcl包，支持Oracle、SQL Server、DB2、MySQL、PostgreSQL、Redis、Trafodion。支持Windows图形界面以及Tcl脚本脚本，功能比较完善。

DBT2简介

Databases Test 2是由Open Source Development Lab开发的用于测试数据库性能的测试工具，虽然没有完全实现TPCC但是基本上也是模拟了OLTP的应用场景的，测试结果包括每秒处理的事务数、CPU使用率、IO以及内存的使用情况

sqlbench简介

sqlbench源自DBT2，作者阿里巴巴 荣生(diancheng.wdc)。原来的DBT2把整个测试过程分成client和 driver 两个应用程序，每个terminal需要 2个线程。如果测试的warehouse较多需要占用机器大量资源。而sqlbench对这方面做了优化，合并了这两个应用程序，同时优 化了线程的使用，使用1个线程处理多个terminal，大大减少了机器资源的使用。使一台机器可以运行更多的warehouse。另外 DBT2外部依赖较多，如对R环境的依赖，sqlbench去掉了不必要的外部依赖，目前sqlbench只依赖测试数据库的客户端库。

数据库支持

sqlbench MySQL, PostgreSQL
tpcc-mysql MySQL
benchmark-sql PostgreSQL, EnterpriseDB and Oracle, MySQL
HammerDB Oracle Database, SQL Server, IBM Db2, MySQL, MariaDB, PostgreSQL and Redis
DBT2 MySQL, PostgreSQL

对sql执行方式的支持

sqlbench plain SQL，prepared statement，stored procedure
tpcc-mysql Prepared statement
benchmarksql Prepared statement
HammerDB Stored Procedure
DBT2 Plain SQL，prepared statement，stored procedure

对key-in time和think time的支持

TPC-C标准规定了每一中交易中的模拟用户输入和对输出结果的思考时间，这使得同一个terminal发起的SQL事务是非常低频率的操作。TPC-C标准通过这两个延迟时间限制了同一个terminal在给定的时间内能完成的交易数量，与此同时标准规定用一时间最多只有10个terminals访问同一个warehouse。经过计算1个warehouse能提供的最多TpmC为12.86。

sqlbench YES
tpcc-mysql NO
benchmark-sql NO
HammerDB NO
DBT2 YES

对terminal和database connection的解耦

TPC-C规定了terminal到事务处理引擎中间必须通过网络连接，但是这里所列出的所有工具都不支持这种架构。DBT2和sqlbench虽然不支持这种三层结构，但是支持terminal处理和DB连接用不同的线程分开，其他几个工具没有terminal的概念，直接通过db connection thread完成交易。

image.png

sqlbench Terminal和DB conneciton解耦，可以单独配置数量。Termial处理线程支持复用，缺省配置每个线程支持50个terminal。
tpcc-mysql 没有terminal，只能配置db connection数量
benchmark-sql 没有terminal，只能配置db connection数量
HammerDB 没有terminal，只能配置db connection数量
DBT2 Terminal和DB conneciton解耦，可以单独配置数量

TPC-C标准中Home Warehouse支持

标准要求每一个terminal在整个测试运行周期内保持warehouse ID不变，即home warehouse不变。

sqlbench 支持terminal home warehouse
tpcc-mysql 不支持，warehouse每个交易随机生成
benchmark-sql 不支持，warehouse每个交易随机生成
HammerDB 支持terminal home warehouse
DBT2 支持terminal home warehouse

Terminal上的可视信息交互

标准定义了用户从terminal输入数据，然后交易结果的细节数据需要返回给terminal用户用于展示，这会带来额外的时延。所有工具都没有对terminal信息交互的支持。

sqlbench

prepare

1
yum install -y autoconf automake mysql mysql-devel postgresql-devel

compile

1
2
3
4
5
6
7
8
git clone https://github.com/swida/sqlbench.git
cd sqlbench
aclocal
autoconf
autoheader
automake --add-missing
./configure --with-postgresql=yes --with-mysql=yes 
make && make install

load 数据

从 https://github.com/longdafeng/test/tree/master/shell/tpcc/sqlbench 上把load.sh 脚本下载下来

1
2
3
4
5
cd sqlbench
cd src/scripts
wget https://raw.githubusercontent.com/longdafeng/test/master/shell/tpcc/sqlbench/load.sh
nohup ./load.sh ipxxxx portxxx userxxx passwordxxx dbnamexxx warehousexxx > load.log 2>&1 &
tail -f load.log
  1. 必须使用ip， 建议不要使用域名， 因为使用域名，经常建立不了到数据库的链接
  2. 脚本是放到${sqlbench_source_dir}/src/scripts 下
  • ipxxxx 数据库的ip
  • portxxx 数据库的端口号
  • userxxx 数据库的用户名
  • password 数据库的密码
  • dbnamexxx 数据库的库名字
  • warehousexxx warehouse 的个数 ， 比如100

运行测试

1
2
3
4
cd sqlbench
# MySQL:
nohup ./src/core/sqlbench -t mysql --dbname=tpcc --user=user --password=password --host=127.0.0.1 --port=3306 -w100 -c32 -l7200 -r1200 --sqlapi=storeproc >run.log 2>&1 &
tail -f run.log

这里:

• -t 指定PostgreSQL数据库 –dbname和–host为数据库的连接参数，其他没指定的使用默认参数
• -w 指定测试数据为100个warehouse
• -l 共运行测试时间为7200秒
• -r 其中ramp up的时间为1200秒
• -c 共使用32个数据库连接
sqlbench其他的常用参数包括：
• –no-thinktime 默认的TPC-C测试是有keying time和thinking time的，模拟真正的用户场景，可通过指定这个参数将相应 的时间设置成0，不控制时间间隔，产生最大压力
• –sqlapi 选择SQL执行的方式，可选：
• simple 为普通SQL方式
• extended 使用prepare/bind/execute方式，该方式先生成查询计划缓存起来，后面直接执行，效率更高
• storeproc 使用存储过程，这种方式与比extended相比还节省了与数据库服务器通信的开销
• -s与-e指定开始和结束的warehouse数，在更多warehouse时，可以使用这2个选项分配warehouse，分成多个sqlbench压测同 一个数据库
• –altered默认情况sqlbench下根据TPC-C标准生成terminal数（每个terminal代表一个user，每个warehouse 10个terminal， 也可以使用–tpw改变），这个参数直接指定了terminal个数，被这些warehouse平均分。
• –sleep指定每创建一个线程后sleep的时间，默认为1s
• -o 用来指定output目录，用来存储错误日志及测试结果文件
sqlbench的其他参数是用来定制TPC-C标准的各个部分的，包括keying time、thinking time的时间，各个事务所占比率，各个 表的数据量等，默认值都是遵从TPC-C标准的。

比如常用

  1. 没有think time控制

    1
    ./src/core/sqlbench -t mysql --dbname=tpcc --user=user --password=password --host=$HOST --port=$PORT -w$WH -c$CONN -l7200 -r1200 --sqlapi=storeproc --no-thinktime --sleep=10

  2. 有think time控制

    1
    2
    ./src/core/sqlbench -t mysql --dbname=tpcc --user=user --password=password --host=$HOST --port=$PORT -w$WH -c$CONN -l7200 -r1200 --sqlapi=storeproc --sleep=10

生成测试报告

1
src/utils/post_process -l mix.log