TIDB 3.0.5 性能压测

作者：杜振强

原文来源： https://tidb.net/blog/cb1c5ea3

1、测试目的

TIDB 2.1 region心跳和raft消息是单线程处理的，在region量比较大(几十上百万)的集群中，虽然写入量不大，但是大量的心跳导致raft的单线程cpu经常打满，进而导致业务响应时间明显增加，在3.0版本raft改成了多线程，性能有明显的提升，这里主要测试TIDB 3.0.5版本的性能数据。

2、测试工具

• 使用 sysbench 1.1.0 作为测试工具
• oltp数据模型：32张表；每张表 40000000 行数据。共使用的磁盘空间为：280G左右。
• 默认收集7种负载情况下的统计数据：oltp_point_select、select_random_points、oltp_read_only、oltp_write_only、oltp_read_write、oltp_update_index、oltp_update_non_index
• 测试工具集： ssh://git@git.xxxxxxx.com/inf/sysbench_for_tidb.git 这个git仓库是公司内部压测tidb专用的仓库，主要脚本有： - 编译安装sysbench脚本 - 根据配置文件构造和清理测试数据脚本 - 根据配置文件压测某一个场景脚本 - 根据配置文件压测所有场景并生成测试日志脚本

3、测试环境

组件 服务器 OS和内核 硬件信息 cpu型号 说明 TIKV xr-tidb-inf-perftestkv01 CentOS Linux release 7.4 32C_128G_PCIE_3.2T_20000 Intel® Xeon® CPU E5-2620 v4 @ 2.10GHz 普通PCIE服务器 TIKV xr-tidb-inf-perftestkv02 同上 32C_128G_PCIE_3.2T_20000 Intel® Xeon® CPU E5-2620 v4 @ 2.10GHz TIKV xr-tidb-inf-perftestkv03 同上 32C_128G_PCIE_3.2T_20000 Intel® Xeon® CPU E5-2620 v4 @ 2.10GHz TIDB xr-tidb-inf-perftestsql01 同上 32C_128G_PCIE_3.2T_20000 Intel® Xeon® CPU E5-2620 v4 @ 2.10GHz 普通PCIE服务器 TIDB xr-tidb-inf-perftestsql02 同上 32C_128G_PCIE_3.2T_20000 Intel® Xeon® CPU E5-2620 v4 @ 2.10GHz TIDB xr-tidb-inf-perftestsql03 同上 32C_128G_PCIE_3.2T_20000 Intel® Xeon® CPU E5-2620 v4 @ 2.10GHz PD xr-tidb-inf-perftestroot01 同上 VM_8C_28G_PCIE_600G_20000 Intel® Xeon® Silver 4110 CPU @ 2.10GHz 标准PCIE虚拟机 PD xr-tidb-inf-perftestroot02 同上 VM_8C_28G_PCIE_600G_20000 Intel® Xeon® Silver 4110 CPU @ 2.10GHz PD xr-tidb-inf-perftestroot03 同上 VM_8C_28G_PCIE_600G_20000 Intel® Xeon® Silver 4110 CPU @ 2.10GHz sysbench施压机器 xr-dba-tidb-archivetest01 同上 48C_192G_SAS_G_20000 Intel® Xeon® CPU E5-2650 v4 @ 2.20GHz 高配SAS应用服务器
机房内 rtt min/avg/max/mdev = 0.065/0.112/0.146/0.021 ms

4、测试场景说明

• oltp_point_select - 主键点查 (SELECT c FROM sbtest14 WHERE id=?)
• select_random_points - 索引点查 (SELECT id, k, c, pad FROM sbtest1 WHERE k IN (%s))
• oltp_read_only - 复杂查询 (单个事务共14个语句，10个 point select，1个sum，1个范围，1个排序，1个distinct)
• oltp_write_only - 单个事务4个语句，1个删除、1个插入、1个update索引和1个非索引列
• oltp_read_write - oltp_read_only + oltp_write_only，1个事务共18个语句
• oltp_update_index - 根据主键更新索引列 (UPDATE sbtest%u SET k=k+1 WHERE id=?)
• oltp_update_non_index - 根据主键更新非索引列（UPDATE sbtest%u SET c=? WHERE id=?）

5、测试步骤

1. 安装部署tidb和sysbench并授权和创建DB
2. 构造测试数据，默认按照 建表->插入数据->创建索引 的顺序执行，对tidb而言时间会比较长，可以根据 tidb的sysbench优化 来减少构造数据的时间
3. 修改sysbench配置文件，例如指定压测TIDB节点和端口、TIDB账号和密码、压测的表个数和数据量、压测线程数、压测时长、每次压测的预热时间等
4. 开启3个screen，分别启动3个sysbench进程压3个TIDB节点并输出到压测结果文件
5. 记录并分析压测结果
6. 压测完成后将相关配置保存后提交到新的GIT分支，主要包括：a.tidb配置文件、b.tikv配置文件、sysbench压测参数配置文件和压测结果文档URL记录

6、数据记录

git分支：remotes/origin/tidb_3.0.5_perftest

commit id：6456dcd

MIN&AVG&99TH：分别对应事务的最小、平均和99分位的执行时间，单位是毫秒(ms)

oltp_point_select

并发数 QPS MIN AVG 99TH 643 315000 0.29 0.61 3.68 2563 406000 0.29 1.86 10.27 512*3 453000 0.28 3.45 16.12

select_random_points

并发数 QPS MIN AVG 99TH 643 55000 0.90 3.49 12.98 2563 42000 0.87 18.32 44.17 512*3 37000 0.88 41.94 97.55

oltp_read_only

并发数 QPS MIN AVG 99TH 643 119000 8.87 22.20 31.37 2563 133000 17.29 79.84 108.68 512*3 129000 16.88 163.37 219.36

oltp_write_only

并发数 QPS MIN AVG 99TH 643 23300 9.36 33.14 57.87 2563 31400 10.32 103.42 227.40 512*3 36200 7.07 183.41 484.44

oltp_read_write

并发数 QPS MIN AVG 99TH 643 64500 26.22 55.87 106.75 2563 89000 34.55 184.38 450.77 512*3 97000 52.54 340.47 846.57

oltp_update_index

并发数 QPS MIN AVG 99TH 643 18800 0.44 10.21 22.28 2563 27300 0.44 28.06 84.47 512*3 31700 0.44 48.40 161.51

oltp_update_non_index

并发数 QPS MIN AVG 99TH 643 28700 0.44 6.68 15.00 2563 49100 0.45 15.63 42.61 512*3 60100 0.45 25.55 84.47

7、结果分析

oltp_write_only场景下，对比以前测试的TIDB 2.1.8版本的结果(除了版本其它场景都相同)如下：
版本 并发数 QPS MIN AVG 99TH 相对2.1.8版本QPS增幅(%) 3.0.5 643 23300 9.36 33.14 57.87 64 2.1.8 643 8210 11.42 93.47 130.13 0 3.0.5 2563 31400 10.32 103.42 227.40 37 2.1.8 2563 19700 25.43 156.07 267.41 0 3.0.5 5123 36200 7.07 183.41 484.44 38 2.1.8 5123 22440 33.73 274.64 493.24 0
从测试结果来看，TIDB 3.0.5的 raft 改成多线程后相同测试场景下，业务的平均响应时间降低非常明显，同时QPS也明显增加，普遍在30+%。

8、结论

升级到 TIDB 3.0.5 对写入的提升非常明显，并且3.0.5也是一个比较稳定的版本，我们经过线上各种场景灰度验证后，已将50多个集群升级到该版本，解决了长期被业务吐槽的写入延迟过大的问题，并且为了达到业务响应时间而增加的TIKV机器也可以节省下来，明显降低了业务的使用成本。