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
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

  1. 有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