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

网友投稿 605 2024-03-07



基于***TiDB的性能压测初体验

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

基于***TiDB的性能压测体验

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

参考文档:

如何用 Sysbench 测试 TiDB

如何对 TiDB 进行 TPC-C 测试

如何对 TiDB 进行 CH-benCHmark 测试

1. 集群环境

1.1 硬件配置

服务类型ECS类型实例数CPU内存备注PDc6.large32 vCore4GTiKVi3.2xlarge38 vCore64GTiDBc6.xlarge24 vCore8GTiFlashi3.2xlarge28 vCore64GControl Serverc6.large12 vCore4G

1.2 软件版本

服务类型软件版本PD6.5TiKV6.5TiDB6.5TiFlash6.5Sysbench1.0.17bench1.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

ThreadsQPS95% latency15056024.444.6530058633.859.3960058821.172090058236.1929.72100057678.533.72

600个并发时QPS最高

Update Index

ThreadsQPS95% latency15012163.2523.5230012748.1946.6360014646.5873.1390015417.34104.84100015311.59123.28

900个并发时QPS最高

Update Non Index

ThreadsQPS95% latency15022690.3910.4630024344.7919.6560024843.8241.190024574.5564.47100024372.971.83

600个并发时,QPS最高

Read Write

ThreadsQPS95% latency15025796.17186.5430024781.79390.360022372.15861.9590021946.181327.91100021932.331479.41

3.2 TPC-C压测结果

ThreadstpmC5039519.310039933.220040109.730038270.840036153.7

200个并发时,tpmc最高

3.3 CH-benCHmark 压测结果

查询ID响应时间(ms)Q113862.2Q217658.0Q320057.2Q427741.1Q599958.7Q614013.2Q736893.1Q823983.0Q9277696.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 ,在压测中他成为了瓶颈,导致压测数据不理想,以后测试的时候需要注意,同时也谢谢老师的反馈。

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:基于Vercel和TiDB Serverless的chatbot开发实践
下一篇:处理TiDB数据库报错的经验分享
相关文章