TiDB5.0.3-ARM 平台性能测试

作者： h5n1 原文来源：https://tidb.net/blog/35891958

【是否原创】是

【首发渠道】TiDB 社区

【首发渠道链接】其他平台首发请附上对应链接

【正文】

一、系统环境

软硬件配置

系统部署

注： 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

整体测试过程如下：

三、数据初始化

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 测试

2*tidb+3*tikv

4*tidb+3*tikv

4*tidb+6*tikv

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 利用率比较均衡

五、测试结论

1. 各压测场景下的最高 tps 如下：

1. TiDB 具备计算节点、存储节点的横向扩展能力，能够实现一键扩缩容操作，tikv 存储节点在扩容期间可以通过调整迁移速度控制 leader、region 的迁移速度。

2. 增加 tidb 实例、tikv 实例均能增加整体 TPS，针对不同场景提升效率有所不同，同时能够降低相同并发数下的平均延迟。

3. 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、系统上线前要进行压力测试以提前找到系统瓶颈并进行调整优化。