如何对 TiDB 进行 TPC-C 测试

    TPC-C 是一个对 OLTP（联机交易处理）系统进行测试的规范，使用一个商品销售模型对 OLTP 系统进行测试，其中包含五类事务：

    • NewOrder – 新订单的生成
    • Payment – 订单付款
    • OrderStatus – 最近订单查询
    • Delivery – 配送
    • StockLevel – 库存缺货状态分析

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

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

    我们将以 1000 WAREHOUSE 为例进行测试。

    TPC-C 使用 tpmC 值（Transactions per Minute）来衡量系统最大有效吞吐量 (MQTh, Max Qualified Throughput)，其中 Transactions 以 NewOrder Transaction 为准，即最终衡量单位为每分钟处理的新订单数。

    本文使用开源的 BenchmarkSQL 5.0 作为 TPC-C 测试实现并添加了对 MySQL 协议的支持，可以通过以下命令下载测试程序:

    安装 java 和 ant，以 CentOS 为例，可以执行以下命令进行安装

    进入 benchmarksql 目录并执行 ant 构建

    1. cd benchmarksql
    2. ant

    对于 1000 WAREHOUSE 我们将在 3 台服务器上部署集群。

    在 3 台服务器的条件下，建议每台机器部署 1 个 TiDB，1 个 PD 和 1 个 TiKV 实例。

    比如这里采用的机器硬件配置是：

    1. NUMA node0 CPU(s):     0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38
    2. NUMA node1 CPU(s):     1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39

    之后可以通过下面的命令来启动 TiDB：

    1. nohup taskset -c 0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38 bin/tidb-server && \
    2. nohup taskset -c 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39 bin/tidb-server

    最后，可以选择部署一个 HAproxy 来进行多个 TiDB node 的负载均衡，推荐配置 nbproc 为 CPU 核数。

    1. [log]
    2. level = "error"
    4. [performance]
    5. # 根据 NUMA 配置，设置单个 TiDB 最大使用的 CPU 核数
    6. max-procs = 20
    8. [prepared_plan_cache]
    9. # 开启 TiDB 配置中的 prepared plan cache，以减少优化执行计划的开销
    10. enabled = true

    TiKV 配置

    开始可以使用基本的配置，压测运行后可以通过观察 Grafana 并参考 进行调整。

    修改 ：

    导入数据通常是整个 TPC-C 测试中最耗时，也是最容易出问题的阶段。

    首先用 MySQL 客户端连接到 TiDB-Server 并执行：

    1. create database tpcc

    之后在 shell 中运行 BenchmarkSQL 建表脚本：

    1. cd run && \
    2. ./runSQL.sh props.mysql sql.mysql/tableCreates.sql && \
    3. ./runSQL.sh props.mysql sql.mysql/indexCreates.sql

    直接使用 BenchmarkSQL 导入

    运行导入数据脚本：

    1. ./runLoader.sh props.mysql

    根据机器配置这个过程可能会持续几个小时。

    由于导入数据量随着 warehouse 的增加而增加，当需要导入 1000 warehouse 以上数据时，可以先用 BenchmarkSQL 生成 csv 文件，再将文件通过 TiDB Lightning（以下简称 Lightning）导入的方式来快速导入。生成的 csv 文件也可以多次复用，节省每次生成所需要的时间。

    修改 BenchmarkSQL 的配置文件

    1. fileLocation=/home/user/csv/  # 存储 csv 文件的目录绝对路径，需保证有足够的空间

    因为最终要使用 Lightning 导入数据，所以 csv 文件名最好符合 Lightning 要求，即 {database}.{table}.csv 的命名法。这里可以将以上配置改为：

      这样生成的 csv 文件名将会是类似 tpcc.bmsql_warehouse.csv 的样式，符合 Lightning 的要求。

      生成 csv 文件

      通过 Lightning 导入

      通过 Lightning 导入数据请参考 Lightning 部署执行章节。这里我们介绍下通过 TiDB Ansible 部署 Lightning 导入数据的方法。

      修改 inventory.ini

      这里最好手动指定清楚部署的 IP、端口、目录，避免各种冲突问题带来的异常，其中 import_dir 的磁盘空间参考 Lightning 部署执行，data_source_dir 就是存储上一节 csv 数据的目录。

      1. [importer_server]
      2. IS1 ansible_host=172.16.5.34 deploy_dir=/data2/is1 tikv_importer_port=13323 import_dir=/data2/import
      4. [lightning_server]
      5. LS1 ansible_host=172.16.5.34 deploy_dir=/data2/ls1 tidb_lightning_pprof_port=23323 data_source_dir=/home/user/csv
      修改 conf/tidb-lightning.yml
      1. mydumper:
      2.     no-schema: true
      3.     csv:
      5.         delimiter: ''
      6.         header: false
      7.         not-null: false
      8.         'null': 'NULL'
      9.         backslash-escape: true
      10.         trim-last-separator: false
      部署 Lightning 和 Importer
      1. ansible-playbook deploy.yml --tags=lightning
      启动
      • 登录到部署 Lightning 和 Importer 的服务器
      • 进入部署目录
      • 在 Importer 目录下执行 scripts/start_importer.sh，启动 Importer
      • 在 Lightning 目录下执行 scripts/start_lightning.sh，开始导入数据

      由于是用 TiDB Ansible 进行部署的，可以在监控页面看到 Lightning 的导入进度，或者通过日志查看导入是否结束。

      导入完成后

      数据导入完成之后，可以运行 sql.common/test.sql 进行数据正确性验证，如果所有 SQL 语句都返回结果为空，即为数据导入正确。

      执行 BenchmarkSQL 测试脚本：

      1. nohup ./runBenchmark.sh props.mysql &> test.log &

      运行结束后通过 test.log 查看结果：

      1. 07:09:53,455 [Thread-351] INFO   jTPCC : Term-00, Measured tpmC (NewOrders) = 77373.25
      2. 07:09:53,455 [Thread-351] INFO   jTPCC : Term-00, Measured tpmTOTAL = 171959.88
      3. 07:09:53,455 [Thread-351] INFO   jTPCC : Term-00, Session Start     = 2019-03-21 07:07:52
      4. 07:09:53,456 [Thread-351] INFO   jTPCC : Term-00, Session End       = 2019-03-21 07:09:53

      tpmC 部分即为测试结果。

      测试完成之后，也可以运行 sql.common/test.sql 进行数据正确性验证，如果所有 SQL 语句的返回结果都为空，即为数据测试过程正确。