0
0
0
0
专栏/.../

TiDB5.0.3-ARM平台性能测试

 h5n1  发表于  2021-10-27

【是否原创】是
【首发渠道】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)

系统部署

image

注: tidb、压测软件、负载均衡、监控(Promethues/grafana)等均部署在一起。

参数设置

image

二、测试内容

在线扩容

(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组直写模式。

系统负载:
image
image
image

TPCC

初始化用时:128线程(3 tikv),用时7小时46分,raid组直写模式。

系统负载:

image


image


image

image


TPS、TPCC全部数据初始化完成后数据大小
image

四、测试结果

在线扩容

扩容前包含3个tikv节点:
image
扩容完成后tikv节点数为6(20181端口):
image
扩容操作如下:

image


添加新tikv节点后的leade和region迁移如下,调整leader迁移速度后leader迁移速度加快,最终tikv节点Leader和region保持均衡
image
扩容期间TiKV CPU 利用率如下:

image

TPS测试

2tidb+3tikv

image


image


image


image

4tidb+3tikv

image


image


image


image

4tidb+6tikv

image


image

image


image

TPS结果对比

image
针对点查增加tidb和tikv实例数量均能明显提供系统吞吐量

image


增加tidb明显增加random_points查询TPS,由于热点问题TPS随并发线程数增加在降低

image


增加tidb实例明显增加random_range查询TPS
image
增加tidb和tikv数量就能提高update_index TPS, 相比增加tikv更明显

image


增加tidb和tikv数量就能提高delete TPS, 相比增加tikv更明显

TPCC测试

测试结果
image
系统负载

image


image

TPCC测试期间tikv CPU利用率比较均衡

image


image

五、测试结论

  1. 各压测场景下的最高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
  1. TiDB具备计算节点、存储节点的横向扩展能力,能够实现一键扩缩容操作,tikv存储节点在扩容期间可以通过调整迁移速度控制leader、region的迁移速度。
  2. 增加tidb实例、tikv实例均能增加整体TPS,针对不同场景提升效率有所不同,同时能够降低相同并发数下的平均延迟。
  3. Tidb server在数量有限情况下随着线程数增加TPS会出现降低情况。

六、遇到的问题

磁盘性能

初期raid0组10块盘使用AWB回写模式,后经dd测试2M块比单盘速度还慢,后咨询厂家建议使用WT直写模式,使用直写模式进行数据初始化,发现速度同样不理想,后dd测试256k块同样比单盘慢,之后改为2个raid0组使用WB回写模式,经测试为性能最高。

image


image


image


读热点

测试过程中发现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 利用率趋于均衡。
image
测试结果如下:

image

七、 总结

1、tidb具备计算、存储资源的横向扩展能力,适用于大规模高并发的oltp系统,能够实现快速的一键扩容,可有效解决分库分表带来的业务入侵、维护复杂等问题。
2、实际生产环境中部署时应尽量独立部署tidb/tikv/pd等组件,如资源限制情况需要使用一台主机部署多个组件或实例时,使用numa绑核可降低系统争用,大幅提升系统性能。
3、CPU、内存、IO资源充足情况下可在同一主机部署多个tikv或tidb实例以提升系统利用率。可利用主机的多网卡,不同实例使用不同网卡。
4、生产环境中尽量是用高性能次,如NVMe SSD,配置为raid10模式,兼顾性能和数据安全。需要对存储配置进行测试以找到最合适的配置策略。
5、系统上线前要进行压力测试以提前找到系统瓶颈并进行调整优化。

0
0
0
0

版权声明:本文为 TiDB 社区用户原创文章,遵循 CC BY-NC-SA 4.0 版权协议,转载请附上原文出处链接和本声明。

评论
暂无评论