TIDB 3.0.5 性能压测

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
64*3 315000 0.29 0.61 3.68
256*3 406000 0.29 1.86 10.27
512*3 453000 0.28 3.45 16.12

select_random_points

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

oltp_read_only

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

oltp_write_only

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

oltp_read_write

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

oltp_update_index

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

oltp_update_non_index

并发数 QPS MIN AVG 99TH
64*3 28700 0.44 6.68 15.00
256*3 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 64*3 23300 9.36 33.14 57.87 64
2.1.8 64*3 8210 11.42 93.47 130.13 0
3.0.5 256*3 31400 10.32 103.42 227.40 37
2.1.8 256*3 19700 25.43 156.07 267.41 0
3.0.5 512*3 36200 7.07 183.41 484.44 38
2.1.8 512*3 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机器也可以节省下来,明显降低了业务的使用成本。