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

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

时间:2023-05-03 10:32:07浏览次数:46  
标签:初体验 压测 TiDB -- tpcc mysql table

作者: 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 参数配置

  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

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

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

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

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

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

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

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



3.2 TPC-C压测结果

Threads

tpmC

50

39519.3

100

39933.2

200

40109.7

300

38270.8

400

36153.7

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

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 ,在压测中他成为了瓶颈,导致压测数据不理想,以后测试的时候需要注意,同时也谢谢老师的反馈。

标签:初体验,压测,TiDB,--,tpcc,mysql,table
From: https://blog.51cto.com/u_15550868/6241114

相关文章

  • 基于 TiCDC 的 TiDB 复制集群的计划内和计划外切换验证步骤
    作者:pepezzzz环境准备集群名称和版本上游tidb集群:tidb-h下游tidb集群:tidb-cdc版本:v6.5.0CDC专用用户:cdcuser注:业务负载用户应独立于CDC专用用户。业务数据库:cdcdb模拟业务应用:Sysbench、BANK。上下游创建ticdc同步用户和数据库createusercdcuseridentified......
  • Hadoop-HDFS压测】针对HDFS进行读写性能测试
    【Hadoop-HDFS压测】针对HDFS进行读写性能测试1)测试工具2)写入数据测试3)读取数据测试4)清除数据1)测试工具Hadoop自身集成的工具包:hadoop-mapreduce-client-jobclient-3.1.1.jar注意:1、如果是Apache版本安装的Hadoop默认在lib目录下,如果是CDH版本安装的Hadoop需要自己去对......
  • rockyLinux 初体验(教程)PostgreSQL15
    目录数据库软件PostgreSQL安装数据库软件PostgreSQL配置数据库软件PostgreSQL交互通用数据库管理软件DBeaver彼时,PostgreSQL已经更新到了15.2。距离我上一次写PostgreSQL教程2022-03-20,已经过去一年多了。Linux篇PostgreSQL教程很久之前就想写了,一直停留在想法上......
  • 如何写压测方案
    压测方案是指在系统稳定性和性能测试中,通过模拟大量用户并发请求,对系统的响应时间、吞吐量、稳定性等关键指标进行测试和评估的方法。下面是一份压测方案的通用步骤:确定压测目标:首先需要明确压测的目标,比如评估系统在高并发情况下的性能表现,找出系统瓶颈等。确定压测环境:根据系......
  • 达梦读写分离分发测试(Jmeter 压测)
    1. 测试目的本次测试目的主要是验证达梦读写分离集群是否生效,查询负载请求是否会自动分发给备库执行2. 达梦读写分离部署(一写一读,过程忽略)配置ip地址实例名端口号数据库版本主库192.168.145.66DM6652364-2-98-21.12.16-153423-10040-SEC......
  • 动力节点老杜Vue框架教程【一】Vue程序初体验
    Vue.js是一个渐进式MVVM框架,目前被广泛使用,也成为前端中最火爆的框架Vue可以按照实际需要逐步进阶使用更多特性,也是前端的必备技能动力节点老杜的Vue2+3全家桶教程已经上线咯!学习地址:https://www.bilibili.com/video/BV17h41137i4/视频将从Vue2开始讲解,一步一个案例,知识点......
  • 老杜Vue实战教程完整版笔记(一)Vue程序初体验
    Vue作为国内使用率最高,最火爆的前端框架学习这门技术也越来越重要~动力节点老杜最新版Vue2+3教程已经上线!还是原来的配方,还是熟悉的味道学习地址:https://www.bilibili.com/video/BV17h41137i4/1Vue程序初体验我们可以先不去了解Vue框架的发展历史、Vue框架有什么特点、Vu......
  • 阿里云1+X云计算开发与运维实战——云监控初体验
    实验概述本实验会自动创建一台已部署Nginx的ECS实例和一台负载均衡SLB实例。首先,使用阿里云云监控的 云服务监控 服务,配置并查看ECS实例和SLB实例的监控数据。然后,设置ECS实例的报警规则,并验证报警规则生效。之后,使用 站点监控 服务,监控已部署Nginx的站点的状态,并设置站点报警......
  • Java开发 - 读写分离初体验
    前言上一篇中,我们介绍了主从复制,相信学过的小伙伴已经能够很好的掌握主从复制的技术,实际上也并没有那么难,虽然没有讲一主多从,多主多从的配置,但是从一主一从的配置中也很容易联想到该怎么配置,你没猜错,就是你想的那样。这篇博客,我们要讲解的东西是主从复制的应用——读写分离。一般来......
  • 阿里云1+X云计算开发与运维实战——负载均衡使用初体验
    本实验通过使用阿里云负载均衡SLB以及对负载均衡SLB后端服务器ECS的权重进行修改,可以快速解决上述的问题。实验目标 完成此实验后,可以掌握的能力有:配置负载均衡SLB的监听规则,并将ECS实例部署到SLB后端;通过设置负载均衡SLB后端服务器ECS的权重值,分配用户访问后端ECS实例的比例。背景......