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、测试步骤
- 安装部署tidb和sysbench并授权和创建DB
- 构造测试数据，默认按照 建表->插入数据->创建索引 的顺序执行，对tidb而言时间会比较长，可以根据tidb的sysbench优化来减少构造数据的时间
- 修改sysbench配置文件，例如指定压测TIDB节点和端口、TIDB账号和密码、压测的表个数和数据量、压测线程数、压测时长、每次压测的预热时间等
- 开启3个screen，分别启动3个sysbench进程压3个TIDB节点并输出到压测结果文件
- 记录并分析压测结果
- 压测完成后将相关配置保存后提交到新的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机器也可以节省下来，明显降低了业务的使用成本。