暂无图片
暂无图片
1
暂无图片
暂无图片
暂无图片

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

原创 Arron 2023-03-07
639

基于阿里云数据库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的性能优化部分

「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论