1
3
2
0
专栏/.../

基于阿里云数据库TiDB的性能压测初体验

 arron  发表于  2023-03-13

基于阿里云数据库TiDB的性能压测初体验

申请阿里云TiDB地址:https://market.aliyun.com/isv-pingcap 的过程,申请和部署过程非常简单直观,按提示一步步来即可,这里就忽略了。

本次实验,主要对该云TiDB集群进行性能测试,使用测试工具有 sysbench,tpcc, CH-benCHmark

参考文档:

1. 集群环境

1.1 硬件配置

服务类型 ECS类型 实例数 CPU 内存 备注
PD c6.large 3 2 vCore 4G
TiKV i3.2xlarge 3 8 vCore 64G
TiDB c6.xlarge 2 4 vCore 8G
TiFlash i3.2xlarge 2 8 vCore 64G
Control Server c6.large 1 2 vCore 4G

1.2 软件版本

服务类型 软件版本
PD 6.5
TiKV 6.5
TiDB 6.5
TiFlash 6.5
Sysbench 1.0.17
bench 1.12.0

1.3 参数配置

  1. TiDB 参数配置
log.level: "error"
prepared-plan-cache.enabled: true
tikv-client.max-batch-wait-time: 2000000
  1. TiKV 参数配置
storage.scheduler-worker-pool-size: 5
raftstore.store-pool-size: 3
raftstore.apply-pool-size: 3
rocksdb.max-background-jobs: 8
server.grpc-concurrency: 6
readpool.unified.max-thread-count: 10
  1. TiDB 全局变量配置
set global tidb_hashagg_final_concurrency=1;
set global tidb_hashagg_partial_concurrency=1;
set global tidb_enable_async_commit = 1;
set global tidb_enable_1pc = 1;
set global tidb_guarantee_linearizability = 0;
set global tidb_enable_clustered_index = 1;
set global tidb_prepared_plan_cache_size=1000;

2. 压测步骤

2.1 Sysbench 测试

sysbench主要对集群做基准测试,主要关注qps 和 延迟

  1. 选择Control Server,远程连接进入shell环境, 安装sysbench
[ecs-assist-user@iZuf69qre7ea5dnxxcfnd1Z ~]$ su - root
Password: 
[root@iZuf69qre7ea5dnxxcfnd1Z ~]# yum install sysbench
[root@iZuf69qre7ea5dnxxcfnd1Z ~]# sysbench --version
sysbench 1.0.17
  1. 建库 sbtest,用于sysbench压测
[ecs-assist-user@iZuf69qre7ea5dnxxcfnd1Z ~]$ mysql -h192.168.44.197 -P4000 -uroot -p
Enter password: 

MySQL [(none)]> create database sbtest;
  1. 初始化压测数据,建16张表,每张表 1千万 数据量
[ecs-assist-user@iZuf69qre7ea5dnxxcfnd1Z ~]$ cd /usr/share/sysbench
[ecs-assist-user@iZuf69qre7ea5dnxxcfnd1Z sysbench]$
sysbench oltp_common \
    --threads=16 \
    --rand-type=uniform \
    --db-driver=mysql \
    --mysql-db=sbtest \
    --mysql-host=192.168.44.197 \
    --mysql-port=4000 \
    --mysql-user=root \
    --mysql-password=admin@123456 \
    prepare --tables=16 --table-size=10000000
  1. 预热数据
sysbench  oltp_common \
  --threads=16 \
  --rand-type=uniform \
  --db-driver=mysql \
  --mysql-db=sbtest \
  --mysql-host=192.168.44.197 \
  --mysql-port=4000 \
  --mysql-user=root \
  --mysql-password=admin@123456 \
  --time=600 \
  --report-interval=10 \
  --tables=16 \
  --table-size=10000000 \
  prewarm
  1. 执行压测命令
sysbench  $testname \
  --threads=16 \
  --rand-type=uniform \
  --db-driver=mysql \
  --mysql-db=sbtest \
  --mysql-host=192.168.44.197 \
  --mysql-port=4000 \
  --mysql-user=root \
  --mysql-password=admin@123456 \
  --time=600 \
  --report-interval=10 \
  --tables=16 \
  --table-size=10000000 \
  run

其中$testname 表示测试case,包括oltp_point_select, oltp_update_index, oltp_update_non_index, oltp_read_write几种,可以调整并发数(threads),每次压测执行10分钟

2.2 TPC-C 测试

TPC-C 是一个对 OLTP(联机交易处理)系统进行测试的规范,使用一个商品销售模型对 OLTP 系统进行测试。

TPC-C 使用 tpmC 值 (Transactions per Minute) 来衡量系统最大有效吞吐量 (MQTh, Max Qualified Throughput),其中 Transactions 以 NewOrder Transaction 为准,即最终衡量单位为每分钟处理的新订单数。

这里使用go-bench工具,支持 tpcc、ch 压测。

  1. 通过tiup 安装 go-bench
tiup install bench
  1. 导入数据,数据库为tpcc,使用1000个 warehouse
tiup bench tpcc -H 192.168.44.197 -P 4000 -U root -p admin@123456 -D tpcc --warehouses 1000 --threads 20 prepare
  1. 执行压测命令
tiup bench tpcc -H 192.168.44.197 -P 4000 -U root -p admin@123456 -D tpcc --warehouses 1000 --threads 50 --time 600s run

测试10分钟,可以调整并发数( threads)

2.3 CH-benCHmark 测试

CH-benCHmark 是包含 TPC-C 和 TPC-H 的混合负载,也是用于测试 HTAP 系统的最常见负载。

这里同样使用go-bench工具。

注:安装go-bench工具包 和 导入 tpcc数据部分,在上面的tpcc测试部分已经做了,这里两步可以省略

  1. 通过tiup 安装 go-bench
tiup install bench
  1. 导入TPC-C数据
tiup bench tpcc -H 192.168.44.197 -P 4000 -U root -p admin@123456 -D tpcc --warehouses 1000 --threads 20 prepare
  1. 导入 TPC-H 所需额外的表和视图
tiup bench ch -H 192.168.44.197 -P 4000 -U root -p admin@123456 -D tpcc prepare
  1. 创建TiFlash副本 默认情况下,TiFlash不会自动同步TiKV的数据,需要执行下面的命令来创建TiFlash副本。创建TiFlash副本后,系统自动实现同步最新数据到TiFlash组件
MySQL [(none)]> alter database tpcc set tiflash replica 2;

通过下面的SQL语句,来观测副本创建状态

MySQL [tpcc]> SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'tpcc';
+--------------+------------+----------+---------------+-----------------+-----------+----------+
| TABLE_SCHEMA | TABLE_NAME | TABLE_ID | REPLICA_COUNT | LOCATION_LABELS | AVAILABLE | PROGRESS |
+--------------+------------+----------+---------------+-----------------+-----------+----------+
| tpcc         | nation     |      353 |             2 |                 |         1 |        1 |
| tpcc         | supplier   |      357 |             2 |                 |         1 |        1 |
| tpcc         | region     |      355 |             2 |                 |         1 |        1 |
| tpcc         | item       |      351 |             2 |                 |         1 |        1 |
| tpcc         | warehouse  |      335 |             2 |                 |         1 |        1 |
| tpcc         | new_order  |      343 |             2 |                 |         1 |        1 |
| tpcc         | history    |      341 |             2 |                 |         1 |        1 |
| tpcc         | stock      |      349 |             2 |                 |         1 |        1 |
| tpcc         | orders     |      345 |             2 |                 |         1 |        1 |
| tpcc         | district   |      337 |             2 |                 |         1 |        1 |
| tpcc         | order_line |      347 |             2 |                 |         1 |        1 |
| tpcc         | customer   |      339 |             2 |                 |         1 |        1 |
+--------------+------------+----------+---------------+-----------------+-----------+----------+
12 rows in set (0.00 sec)

当看到所有表的AVAILABLE=1 , PROGRESS=1,表示tpcc库上所有表的TiFlash副本同步完成

  1. 搜集统计信息
analyze table customer;
analyze table district;
analyze table history;
analyze table item;
analyze table new_order;
analyze table order_line;
analyze table orders;
analyze table stock;
analyze table warehouse;
analyze table nation;
analyze table region;
analyze table supplier;
  1. 执行压测命令
tiup bench ch -H 192.168.44.197 -P 4000 -U root -p admin@123456 -D tpcc --warehouses 1000 -T 50 -t 1 --time 30m run

这里压测跑 50 TP 并发,1 AP 并发,跑30分钟

3. 压测结果

3.1 sysbench压测结果

  1. Point Select
Threads QPS 95% latency
150 56024.44 4.65
300 58633.85 9.39
600 58821.17 20
900 58236.19 29.72
1000 57678.5 33.72

image.png

600个并发时QPS最高

  1. Update Index
Threads QPS 95% latency
150 12163.25 23.52
300 12748.19 46.63
600 14646.58 73.13
900 15417.34 104.84
1000 15311.59 123.28

image.png

900个并发时QPS最高

  1. Update Non Index
Threads QPS 95% latency
150 22690.39 10.46
300 24344.79 19.65
600 24843.82 41.1
900 24574.55 64.47
1000 24372.9 71.83

image.png

600个并发时,QPS最高

  1. Read Write
Threads QPS 95% latency
150 25796.17 186.54
300 24781.79 390.3
600 22372.15 861.95
900 21946.18 1327.91
1000 21932.33 1479.41

image.png

3.2 TPC-C压测结果

Threads tpmC
50 39519.3
100 39933.2
200 40109.7
300 38270.8
400 36153.7

image.png

200个并发时,tpmc最高

3.3 CH-benCHmark 压测结果

查询ID 响应时间(ms)
Q1 13862.2
Q2 17658.0
Q3 20057.2
Q4 27741.1
Q5 99958.7
Q6 14013.2
Q7 36893.1
Q8 23983.0
Q9 277696.5

Q10以后的查询报错,没有跑成功

4. 总结

阿里云提供的试用版本的TiDB,基本能够完成常规的OLTP,OLAP操作。

但是由于刚接触TiDB集群,对集群的性能优化这块不太数据,对测试结果比较疑惑

  1. Sysbench在各种查询下,并发在600左右下,QPS最高
  2. TPC-C在200个并发下最高,后面成下降趋势
  3. CH-benCHmark 中的查询SQL,Q10出错,后续的Q11-Q22都没跑

这里只是先做个简单记录,后续有机会的话再深入研究一下TiDB的性能优化部分

PS:通过跟TiDB老师反馈,了解到上面压测不理想的原因在于Control Server机器的配置比较低,只有2c ,在压测中他成为了瓶颈,导致压测数据不理想,以后测试的时候需要注意,同时也谢谢老师的反馈。

1
3
2
0

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

评论
暂无评论