3.2 TPC-C 基准性能测试

    TPC 是一系列事务处理和数据库基准测试的规范。其中TPC-C（Transaction Processing Performance Council）是针对 OLTP 的基准测试模型。TPC-C 测试模型给基准测试提供了一种统一的测试标准，可以大体观察出数据库服务稳定性、性能以及系统性能等一系列问题。对数据库展开 TPC-C 基准性能测试，一方面可以衡量数据库的性能，另一方面可以衡量采用不同硬件软件系统的性价比，也是被业内广泛应用并关注的一种测试模型。

    我们这里以经典的开源数据库测试工具 BenchmarkSQL 为例，其内嵌了 TPCC 测试脚本，可以对 PostgreSQL、MySQL、Oracle、TIDB 等行业内主流的数据库产品直接进行测试。

    2. BenchmarkSQL

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

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

    在测试开始前，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 记录。

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

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

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

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

    因为该型号 CPU 是 NUMA 架构，建议先用 进行绑核，首先用 lscpu 查看 NUMA node，比如：

    之后可以通过下面的命令来启动 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 核数。

    TIDB TIKV PD
    node1 1 1 1
    node2 1 1 1
    node3 1 1 1

    4. TIDB 调优配置

    1、升高日志级别，可以减少打印日志数量，对性能有积极影响。 

    1. [log]
    2. level = "error"
    1. performance:
    2.   max-procs: 20

    3、缓存语句数量设置，开启 TiDB 配置中的 prepared plan cache，可减少优化执行计划的开销。

    1. prepared_plan_cache:
    2.   enabled: true

    4、与 TiKV 客户端相关的设置，默认值为 16；当节点负载比较低时，可适当调大该值。

    1. tikv_client:
    2. # Max gRPC connections that will be established with each tikv-server.
    3.   grpc-connection-count: 4

    5、本地事务冲突检测设置，并发压测时建议开启，可减少事务的冲突。

    1. txn_local_latches:
    2. # Enable local latches for transactions. Enable it when
    3. # there are lots of conflicts between transactions.
    4.   enabled: true

    1、调整日志级别，升高 TiKV 的日志级别同样有利于性能表现。

    2、关闭 sync-log，由于TiKV 是以集群形式部署，在 Raft 算法的作用下，能保证大多数节点已经写入数据，除了对数据安全极端敏感的场景之外，raftstore 中的 sync-log 选项可以关闭。

    1. [raftstore]
    2. sync-log = false

    3、块缓存配置，在 TiKV 中需要根据机器内存大小配置 RocksDB 的 block cache，以充分利用内存。以 20 GB 内存的虚拟机部署一个TiKV 为例，其 block cache 建议配置如下。

    2. capacity = "10GB"

    3、开始可以使用基本的配置，压测运行后可以通过观察 Grafana 并参考 [TiKV 调优说明]进行调整。如出现单线程模块瓶颈，可以通过扩展 TiKV 节点来进行负载均摊；如出现多线程模块瓶颈，可以通过增加该模块并发度进行调整。

    6. BenchmarkSQL 配置

    修改 benchmarksql/run/props.mysql 文件

    1. conn=jdbc:mysql://{HAPROXY-HOST}:{HAPROXY-PORT}/tpcc?useSSL=false&useServerPrepStmts=true&useConfigs=maxPerformance
    3. warehouses=1000 # 使用 1000 个 warehouse
    5. terminals=500   # 使用 500 个终端
    7. loadWorkers=32  # 导入数据的并发数

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

    1、首先连接到 TiDB-Server 并执行：

    1. create database tpcc；

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

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

    3、数据导入有两种方式可以选取，主要如下：

    1. ./runLoader.sh props.mysql

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

    a、修改 BenchmarkSQL 的配置文件 warehouse 的 csv 文件需要 77 MB 磁盘空间，在生成之前要根据需要分配足够的磁盘空间来保存 csv 文件。可以在 benchmarksql/run/props.mysql 文件中增加一行：

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

    1. fileLocation=/home/user/csv/tpcc.  # 存储 csv 文件的目录绝对路径 + 文件名前缀（database）

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

    b、生成 csv 文件

    1. ./runLoader.sh props.mysql

    c、修改 inventory.ini

    建议手动指定清楚部署的 IP、端口、目录，避免各种冲突问题带来的异常。

    1. [importer_server]
    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

    d、修改 conf/tidb-lightning.yml

    1. mydumper:
    2.   no-schema: true
    3. csv:
    4.   separator: ','
    5.   delimiter: ''
    6.   header: false
    7.   not-null: false
    8.   'null': 'NULL'
    9.   backslash-escape: true
    10.   trim-last-separator: false

    e、部署 Lightning 和 Importer

    1. ansible-playbook deploy.yml --tags=lightning

    f、启动

    • 登录到部署 Lightning 和 Importer 的服务器；
    • 进入部署目录；
    • 在 Importer 目录下执行 scripts/start_importer.sh，启动 Importer；

    由于是用 ansible 进行部署的，可以在监控页面看到 Lightning 的导入进度，或者通过日志查看导入是否结束。数据导入完成之后，可以运行 sql.common/test.sql 进行数据正确性验证，如果所有 SQL 语句都返回结果为空，即为数据导入正确。

    8. 运行测试

    执行 BenchmarkSQL 测试脚本：

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

    tpmC 部分即为测试结果。