TiDB 压力测试报告

TiDB 压力测试报告

(转载自公众号DBATech)

一、测试环境

1、tidb 集群架构:

测试使用最基本的TiDB架构。即 3个tidb-server节点+ 3个tikv节点 + 3个pd节点。

 

2、tidb集群的部署环境(混合部署):

192.168.xx.A 1*server +1*PD +1*tikv

192.168.xx.B 1*server +1*PD +1*tikv

192.168.xx.C 1*server +1*PD+1*tikv

IDC机器环境:

0S :CentOS7

CPU :Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz  *24

RAM :48GB

DISK :SSD, 480GB RAID0

 

TiDB 重要配置参数

以下这些参数都是会对tidb造成性能影响的参数。设置尽量折中。较少对性能的影响。

tidb-server节点的设置:

[log]

level = "warn"

[prepared-plan-cache]

enabled = true

log-level = "warning"

[raftstore]

sync-log = false

 tikv节点的设置:

log-level = "warning"

[rocksdb.defaultcf]

[rocksdb.writecf]

block-cache-size = "6GB"    #关于写的缓存块大小  大概设置为读的1/3

max-background-jobs = 8  #后台线程,用于压缩数据与刷新数据

[raftstore]

sync-log = false

[storage.block-cache]

capacity = "20GB"   # 3.0之后 tikv的缓存,包括  rocksdb.defaultcf rocksdb.writecf  rocksdb.lockcf raftdb.defaultcf 都由改参数设置,缓存共享。

集群正常启动后,在每个节点执行以下语句,关闭 失败事务重试。

set global tidb_disable_txn_auto_retry = off

3、sysbench client:

6 台机器 sysbench client (配置与tidb-server机器一模一样)。每次测试6个机器同时发起6个sysbench进程。sysbech client 均匀连接到 3 tidb-server节点上(每2台sysbench client 连接一个tidb-server节点)

由于测试由6个机器并发发起,因此执行结果的 TPS QPS error  reconnects 是 6 个sysbench client 之和。min max 为 6个节点的最小于最大值。avg 95th 为6个节点值的平均值。

sysbench 压测语句如下:

sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=xxxx --mysql-port=xxxx --mysql-user=xxxx --mysql-password=xxxx --mysql-db=sysbench --db-driver=mysql --tables=50 --table-size=10000000 --report-interval=1 --threads=[线程从2-24变化]  --rand-type=uniform   --time=300 --max-requests=0  run

说明:每个sysbech client一次发起长达300秒测试。--max-requests=0 表示不限制测试达到的总qps。

测试数据准备:

sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=xxxx --mysql-port=xxxx --mysql-user=xxxx --mysql-password=xxxx --mysql-db=sysbench --db-driver=mysql --tables=50 --table-size=10000000 --report-interval=100 --threads=24  --rand-type=uniform   --time=0 --max-requests=0 prepare

数据量:50张表,每个表1000万数据。大约200GB数据。缓存参数capacity为20GB。缓存与持久化数据比例 大约为1:10

 

5 测试脚本:

本猿编写一小py小脚本( https://github.com/jiasirVan/dbtool/blob/master/bench2.py ) 。

配置文件sysbench.cnf:

[mysql]

ip=192.168.xx.x

port=xxxx

user=xxxx

password=xxxx

dbname=sysbench

[sysbench]

#生成的表数量

table_amount=50

#限制总的执行时间(秒) 0表示不限制

exectime=300

#每个表初始化多少行数据

rows=10000000

#请求的最大数目。默认为1000000,0代表不限制

max_request=0

#每n秒输出一次测试进度报告

interval=10

#指定sysbench的输出日志目录

logdir=/tmp/log

##并发压测的线程数

threadnumber=2,4,6,8,10,12,14,16,18,20,22,24

#指定用哪个lua脚本测试

lua_script=/usr/share/sysbench/oltp_update_index.lua

 

执行脚本:./bench2.py  -c sysbench.cnf  -r -f  

测试结果直接格式化输出,大约如下(每一行为配置文件的一个threadnumber值,例如以下的2,4,6线程的输出)。

输出结果:

TPS    QPS    error/s    reconnects/s    min    avg    max    95th 

110.98    1775.60    0.00    0.00    10.95    18.02    164.74    23.10

250.54    4008.68    0.00    0.00    9.72    15.96    243.09    19.65

415.15    6642.39    0.00    0.00    9.04    14.45    281.74    18.28

 


 

二、sysbench测试说明:

sysbench mysql 的测试类型:

#1. bulk_insert.lua  批量写入操作

#2. oltp_delete.lua 写入和删除并行操作

#3. oltp_insert.lua  纯写入操作

#4. oltp_point_select.lua  只读操作,条件为唯一索引列

#5. oltp_read_only.lua  只读操作,包含聚合,去重等操作 大多数情况用于统计的压测

#6. oltp_read_write.lua 读写混合操作,最常用的脚本  用于oltp系统的压测。

#7. oltp_update_index.lua 更新操作,通过主键进行更新

#8. oltp_update_non_index.lua 更新操作,不通过索引列

#9. oltp_write_only.lua 纯写操作,常用脚本,包括insert update delete

#10. select_random_points.lua 随机集合只读操作,常用脚本,聚集索引列的selete in操作

#11. select_random_ranges.lua 随机范围只读操作,常用脚本,聚集索引列的selete between操作

注:因为sysbench测试客户端机器与tidb服务器都在同机房。网络ping延迟大约为0.08ms 。可以忽略不计。

 


三 、开始测试

 

说明:所有的tidb-server与 sysbench 测试机器在同机房,多次ping 网络延迟大约在0.08ms左右,可以忽略不计。

 

1、唯一索引只读压测:

TiDB 压力测试报告_第1张图片

 

结论: 唯一索引读是数据库最高效的查询操作。从上图看,唯一索引select 的qps 在 client thread 并发达到 108 之后增长趋于平缓。大约qps在10万左右。平均时延也相对较低。在1ms以下。越大的并发,平均qps时延增加。

 


 

2、只读压测(包括聚合,去重,关联等复杂查询

TiDB 压力测试报告_第2张图片

结论:以上是各类读操作,包括 聚合,关联,去重等复杂的select操作的压测结果。比较符合分析系统型压测。根据上图压测,QPS 在 client thread 108 之后增长趋于平缓。QPS 大约在55000左右。


 

3、读写混合测试(读写比例为默认的7:3):

TiDB 压力测试报告_第3张图片

结论:读写混合压测针对OLTP在线系统,压测结果展示 ,大约在 client thread 为108并发之后,QPS增长趋于平缓。在 40000左右。时延随着并发数的增加不断的增大。

 


4、总结:

通过以上压测。架构为 3 tikv + 3 tidb-server+ 3 pd 架构的tidb分布式集群 在给定环境的下性能表现很好。client thread 并发支持在108 线程达到最大。继续增大并发,QPS 增长并不明显,会增大操作时延。在读写混合型的oltp系统中,QPS 达到 40000万左右。并发上比mysql更优,得益于tidb的分布式架构。但对于单个简单查询语句,mysql的响应时间更快。在大部分OLTP 系统上,都是简单select操作,tidb的响应时间在1毫秒一下。与mysql 相差不大。但 tidb 的分布式架构 支持更好的横向扩展。

 

转载于:https://www.cnblogs.com/vansky/p/11366836.html

你可能感兴趣的:(TiDB 压力测试报告)