【是否原创】是
【首发渠道】TiDB 社区
【首发渠道链接】其他平台首发请附上对应链接
【正文】
一、系统环境
软硬件配置
| 数据库 | TiDB 5.0.3(当前最新版5.2.1) |
|---|---|
| 负载均衡 | HAProxy 2.5 |
| 压测软件 | Sysbench 1.0.20、TiUP-bench v1.5.6 |
| 硬件配置 | 3台：Kunpeng 920（2*48c 2.6GHz）2/32G8/480G[SSD]*2/960G[SSD]10(raid02) |
系统部署
注： tidb、压测软件、负载均衡、监控(Promethues/grafana)等均部署在一起。
参数设置
二、测试内容
在线扩容
（1）每主机有2个raid0组，初始创建3个tikv存储节点,挂接目录/data，每主机1个tikv使用1个raid组。
（2）使用sysbench（128线程）进行oltp_read_write读写操作。
（3）连续增加3个tikv存储节点检测是否能够实现存储节点一键扩容，挂接目录/data1,达到每主机2个tikv节点，各使用1个raid组，共计6个tikv实例。
（4）扩容命令：
tiup cluster scale-out cluster_name tikv.yaml
TPS测试
1、使用sysbench初始化5张1亿条记录表
2、 按照oltp_point_select、select_random_points、select_random_ranges、oltp_update_index、oltp_delete顺序连续测试128、256、512、1024、2048线程下的TPS和平均延迟，每次压测10分钟。
3、 首先使用2个tidb server，numa_node绑定0,1。然后使用4个tidb server，numa_node分别绑定0,1，测试系统吞吐量增长情况(3 tikv实例)。
4、 完成tikv存储节点扩容测试后，再次执行TPS压测, 测试系统吞吐量增长情况(6 tikv实例)。
5、 sysbench测试命令
sysbench /usr/local/share/sysbench/oltp_insert.lua --mysql-host=10.125.144.18 --mysql-port=xxxx --mysql-user=sbtest --mysql-password=xxxxxx --tables=5 --table-size=100000000 --mysql-db=test --auto_inc=on --create_secondary=true --threads=256 --time=600 --report-interval=15 run
TPCC测试
使用tiup-bench初始化5000个warehouse分别进行500、1000、2000、3000、4000、5000并发及3 tikv实例、6 tikv实例的的tpmC(4 tidb server)，每次压测30分钟。
Tiup-bench测试命令：
numactl --cpunodebind=0,1 /home/tidb/.tiup/components/bench/v1.5.6/tiup-bench tpcc --warehouses 5000 run -D tpcc -H10.125.144.18 -Pxxxx -Utpcc -p’xxxxxx’ --time 30m --interval 300s --threads 500
整体测试过程如下：
| 序号 | 测试内容 | tidb实例数 | tikv实例数 | 备注 |
|---|---|---|---|---|
| 1 | sysbench TPS测试 | 2 | 3 | 每tidb/tikv实例绑定2个cpu node |
| 2 | sysbench TPS测试 | 4 | 3 | 每tidb绑定1个node,tikv绑定2个cpu node |
| 3 | Tiup-bench TPCC测试 | 4 | 3 | |
| 4 | Tikv 实例在线扩容测试 | 4 | 3 | |
| 5 | sysbench TPS测试 | 4 | 6 | 每tidb/tikv实例分别绑定1个cpu node |
| 6 | Tiup-bench TPCC测试 | 4 | 6 |
三、数据初始化
TPS
初始化用时：5张表，58分钟(3 tikv)， raid组直写模式。
系统负载：
TPCC
初始化用时：128线程(3 tikv)，用时7小时46分，raid组直写模式。
系统负载：
TPS、TPCC全部数据初始化完成后数据大小
四、测试结果
在线扩容
扩容前包含3个tikv节点：
扩容完成后tikv节点数为6(20181端口)：
扩容操作如下:
添加新tikv节点后的leade和region迁移如下，调整leader迁移速度后leader迁移速度加快，最终tikv节点Leader和region保持均衡
扩容期间TiKV CPU 利用率如下：
TPS测试
2tidb+3tikv
4tidb+3tikv
4tidb+6tikv
TPS结果对比
针对点查增加tidb和tikv实例数量均能明显提供系统吞吐量
增加tidb明显增加random_points查询TPS，由于热点问题TPS随并发线程数增加在降低
增加tidb实例明显增加random_range查询TPS
增加tidb和tikv数量就能提高update_index TPS, 相比增加tikv更明显
增加tidb和tikv数量就能提高delete TPS, 相比增加tikv更明显
TPCC测试
测试结果
系统负载
TPCC测试期间tikv CPU利用率比较均衡
五、测试结论
- 各压测场景下的最高tps如下：
| 场景 | TPS | 平均延迟延迟(ms) | 线程数 | 配置 |
|---|---|---|---|---|
| oltp_point_select | 535282.60 | 1.9 | 1024 | 4tidb+6tikv |
| select_random_points | 88099.79 | 2.90 | 256 | 4tidb+6tikv |
| select_random _ranges | 102398.32 | 10.00 | 1024 | 4tidb+6tikv |
| oltp_update_index | 420482.13 | 4.87 | 2048 | 4tidb+6tikv |
| oltp_delete | 448408.43 | 4.57 | 2048 | 4tidb+6tikv |
- TiDB具备计算节点、存储节点的横向扩展能力，能够实现一键扩缩容操作，tikv存储节点在扩容期间可以通过调整迁移速度控制leader、region的迁移速度。
- 增加tidb实例、tikv实例均能增加整体TPS，针对不同场景提升效率有所不同，同时能够降低相同并发数下的平均延迟。
- Tidb server在数量有限情况下随着线程数增加TPS会出现降低情况。
六、遇到的问题
磁盘性能
初期raid0组10块盘使用AWB回写模式，后经dd测试2M块比单盘速度还慢，后咨询厂家建议使用WT直写模式，使用直写模式进行数据初始化，发现速度同样不理想，后dd测试256k块同样比单盘慢，之后改为2个raid0组使用WB回写模式，经测试为性能最高。
读热点
测试过程中发现select_range_pioint出现随着并发增高TPS下降情况，select_range_pioint使用多个in进行查询，查询时产生热点读，tikv 读线程CPU利用率不均衡。针对读写热点问题可以使用AUTO_RANDOM、shard_rowid_bits、pre-split region、hash分区、load base split、store leader weight等功能降低读写热点问题。
在1024线程下测试select_range_pioint，经调整store leader weight方式后，tikv cpu 利用率趋于均衡。
测试结果如下：
七、 总结
1、tidb具备计算、存储资源的横向扩展能力，适用于大规模高并发的oltp系统，能够实现快速的一键扩容，可有效解决分库分表带来的业务入侵、维护复杂等问题。
2、实际生产环境中部署时应尽量独立部署tidb/tikv/pd等组件，如资源限制情况需要使用一台主机部署多个组件或实例时，使用numa绑核可降低系统争用，大幅提升系统性能。
3、CPU、内存、IO资源充足情况下可在同一主机部署多个tikv或tidb实例以提升系统利用率。可利用主机的多网卡，不同实例使用不同网卡。
4、生产环境中尽量是用高性能次，如NVMe SSD，配置为raid10模式，兼顾性能和数据安全。需要对存储配置进行测试以找到最合适的配置策略。
5、系统上线前要进行压力测试以提前找到系统瓶颈并进行调整优化。