作者: arron
基于阿里云数据库TiDB的性能压测初体验
申请阿里云TiDB地址:https://market.aliyun.com/isv-pingcap
的过程,申请和部署过程非常简单直观,按提示一步步来即可,这里就忽略了。
本次实验,主要对该云TiDB集群进行性能测试,使用测试工具有 sysbench,tpcc, CH-benCHmark
参考文档:
- 如何用 Sysbench 测试 TiDB
- 如何对 TiDB 进行 TPC-C 测试
- 如何对 TiDB 进行 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 参数配置
- TiDB 参数配置
log.level: "error"
prepared-plan-cache.enabled: true
tikv-client.max-batch-wait-time: 2000000
- 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
- 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 和 延迟
- 选择Control Server,远程连接进入shell环境, 安装sysbench
[ecs-assist-user@iZuf69qre7ea5dnxxcfnd1Z ~]$ su - root
Password:
[root@iZuf69qre7ea5dnxxcfnd1Z ~]# yum install sysbench
[root@iZuf69qre7ea5dnxxcfnd1Z ~]# sysbench --version
sysbench 1.0.17
- 建库 sbtest,用于sysbench压测
[ecs-assist-user@iZuf69qre7ea5dnxxcfnd1Z ~]$ mysql -h192.168.44.197 -P4000 -uroot -p
Enter password:
MySQL [(none)]> create database sbtest;
- 初始化压测数据,建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
- 预热数据
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
- 执行压测命令
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 压测。
- 通过tiup 安装 go-bench
tiup install bench
- 导入数据,数据库为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
- 执行压测命令
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测试部分已经做了,这里两步可以省略
- 通过tiup 安装 go-bench
tiup install bench
- 导入TPC-C数据
tiup bench tpcc -H 192.168.44.197 -P 4000 -U root -p admin@123456 -D tpcc --warehouses 1000 --threads 20 prepare
- 导入 TPC-H 所需额外的表和视图
tiup bench ch -H 192.168.44.197 -P 4000 -U root -p admin@123456 -D tpcc prepare
- 创建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副本同步完成
- 搜集统计信息
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;
- 执行压测命令
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压测结果
- 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 |
600个并发时QPS最高
- 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 |
900个并发时QPS最高
- 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 |
600个并发时,QPS最高
- 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 |
3.2 TPC-C压测结果
Threads | tpmC |
50 | 39519.3 |
100 | 39933.2 |
200 | 40109.7 |
300 | 38270.8 |
400 | 36153.7 |
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集群,对集群的性能优化这块不太数据,对测试结果比较疑惑
- Sysbench在各种查询下,并发在600左右下,QPS最高
- TPC-C在200个并发下最高,后面成下降趋势
- CH-benCHmark 中的查询SQL,Q10出错,后续的Q11-Q22都没跑
这里只是先做个简单记录,后续有机会的话再深入研究一下TiDB的性能优化部分
PS:通过跟TiDB老师反馈,了解到上面压测不理想的原因在于Control Server机器的配置比较低,只有2c ,在压测中他成为了瓶颈,导致压测数据不理想,以后测试的时候需要注意,同时也谢谢老师的反馈。
标签:初体验,压测,TiDB,--,tpcc,mysql,table From: https://blog.51cto.com/u_15550868/6241114