分布式 | BenchmarkSQL 压测 dble 性能调优指南

作者:蔡玮

中间件dble测试成员,主要负责dble的日常测试工作,热衷于探索发现,学习新技术。

本文来源:原创投稿

*爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。


背景介绍

BenchmarkSQL 是一个支持众多关系型数据库的基准测试工具,通过使用 BenchmarkSQL 对数据库进行 TPC-C 标准测试,即模拟多种事务处理:新订单、支付操作、订单状态查询、发货、库存状态查询等,从而获得最终的压测值。相较于 Sysbench 的单一,它更能贴切的模拟出真实的应用场景,因此越来越多的客户在对数据库进行压测时,更多的选择使用 BenchmarkSQL 。

作为一款数据库中间件,dble 同样也是可以使用 BenchmarkSQL 进行压测的,但是压测压测过程中,往往如何调优,从而测得产品得最大压测值则是更值得关注的,本文将从可观测角度,绕开内部逻辑,介绍我们内部在使用 BenchmarkSQL 压测 dble 时的一些调优经验总结以及观测手法,以供大家参考。这种调优手段主要集中在配置以及 dble 内部线程数上。

配置建议

本文主要针对的是调优借鉴,在这里就不再过分的介绍 BenchmarkSQL 安装以及 dble 安装等过程,也将不再就数据准备以及压测步骤展开进行叙述。

但是有必要就一些必要配置信息做一些必要以及建议值的简要说明。

后端连接数

需要确保压测时,dble用户连接数 > 压测并发数
dble 中存储节点最大连接数 = 对应后端 MySQL 的最大连接数 >> (并发数 / 存储接节点数量)

日志级别

建议将 dble 的日志级别设置为 WARN ,设置的对应配置文件为 dble/conf/log4j2.xml

隔离级别

dble和后端数据库的隔离级别设置为RC隔离级别,如果是RR隔离级别会在压测过程中出现锁等待超时的报错,原因可参考历史公众号文章:https://mp.weixin.qq.com/s/-2I39hukyUb8qpzMmftfFA

关闭dble可能会影响性能的参数开关

建议关闭 dble 中一些可能会影响性能的参数开关,其他的开关如果非必要均可以关闭,如:useSqlStat=0,enableSlowLog=0

dble的配置

至于 dble 的配置信息,需要额外关注的是,在压测时需要将 config 以及 item 表设置为全局表,其他表全部设置为分片表,同时为了确保后端数据库压力的均匀分配,应当确保分片表的数据均匀分布在后端数据库上,这里建议采用求模算法,以便于达到目的

MySQL 的配置

至于 MySQL 的性能参数配置信息,需要根据机器配置自行调优,在这里不再赘述

观测手段

系统资源观测工具

在使用压测工具进行压测时,选择一款简单好用的系统观测工具有时候也是很重要的,以便于我们观测瓶颈所在并进行一些可尝试的调优。这里推荐使用 dstat 工具,其可以实时地看到所有系统资源,例如,CPU 使用情况、磁盘 IO 以及 网络 IO情况。

dstat 更可以将观测到的结果输入到 csv 文件,以便于后续绘图等分析。

以下为 dstat 的实时输出结果,详情可参考 https://linux.cn/article-3215-1.html

分布式 | BenchmarkSQL 压测 dble 性能调优指南_第1张图片

dble侧观测手段

这里提供两种dble侧可以使用的观测手法:

  • 开启查询耗时统
    需要在dble bootstrap.cnf中开启 useCostTimeStat=1,并重启dble生效,以下为观测样图:

DBLE 将查询分为了六个阶段:

1)开始梳理

2)完成解析

3)完成路由分配

4)从数据库回收结果

5)后置处理

6)反馈处理

我们只需要重点关注 WallTime.Avg ,其指代了每个阶段的平均耗时,这样我们可知道压力到底在中间件的哪一个阶段变慢。然后根据不同阶段的耗时异常,去调整 dble 内部的线程数或者排查后端mysql。详情可参考:https://actiontech.github.io/dble-docs-cn/2.Function/2.18_performance_observation.html

  • 查看线程使用率

dble 内部提供了查看各类线程使用率的命令:show @@thread_used ,借助此命令可以在压测过程中查看各类线程的使用情况,然后进行相应的线程数量调整,以下为命令展示样图。

分布式 | BenchmarkSQL 压测 dble 性能调优指南_第2张图片

压测经验

在我们刚开始去使用 BenchmarkSQL 去压测 dble 时,同样也并不是很清楚各类线程数的大小对于性能的正负影响,都是在一步步的摸索中,才慢慢得到了初步的结论,在此给大家介绍一下相关的情况。

关于 dstat

由于 dstat 主要用于资源占用观测,所以在测试的过程中,作为辅助性工具使用一直打开,用于观察资源使用情况。并未作为调整的依据。

关于查询耗时统计

我们首先使用了 dble 内部的耗时统计功能【useCostTimeStat=1】,去测试不同阶段的耗时情况,然后根据 SQL 执行不同阶段的耗时情况调整线程数。但是测试时发现,调整了线程数并不能有效解决观测到的耗时异常情况,说明这些耗时异常情况并不适用于通过线程数上的调整去解决问题,这也是通过 BenchmarkSQL 压测 dble 时所发现的一问题之一,对此我们也有记录,并会持续的跟进调查。

关于 show 命令

由于依据查询耗时统计去调整 dble 的线程数量,并未起到良好的效果。所以,在压测过程中,管理端命令 show @@thread_used 观测线程使用情况,就成了我们调整线程数量的主要依据。

按照其他压测工具压测 dble 的经验,在压测之初我们也想着确保各类线程的使用率在80%以下,确保线程不那么繁忙,可是测试中发现,在调整各类线程数将各类线程使用率降至80%之后,有时得到了压测 tpmC 值反而不升反降了,猜想,难道是线程数量过多,频繁的线程切换影响性能,那反之又该如何?

所以下一步我们的方向,则是将dble内部的线程按照类型分为三类:

  • 前后端IO线程:processors、backendProcessors
  • 前后端业务处理线程:processorExecutor、backendProcessorExecutor
  • 其他线程:complexExecutor、writeToBackendExecutor

参照 show @@thread_used 查询出来的线程使用率,按照不同类型的线程进行数量上的上下调整。

在调整的过程中我们发现,不同类型线程数量的上下调整,对于压测结果,效果是不一样的。经过多轮测试得到以下结论:

  • 前后端 IO 线程 及 complexExecutor、writeToBackendExecutor的数量对于压测 tpmC 的值没有明显影响
  • 对于tpmC值影响最大的为前后端业务处理线程数量,且前后端业务处理线程使用率与 tpmC的值正向相关,即前后端业务处理线程的线程使用率越高,tpmC 的值越高
  • dble 所在机器的网络 IO 与 tpmC 的值正向相关,即网络 IO 越高,tpmC的值越高【通过观察 dstat 的结果而得】
  • 前后端业务处理线程数量调整,对于 dble 所在机器的网络 IO 与前后端业务处理线程使用率影响一致,即前后端业务处理线程数量下调, 网络 IO 上升、线程使用率上升,且 tpmC 值越高

总结

通过以上的调整手段,在配置不变的情况下,基于 dble 3.20.10.0 版本,我们内部在压测时得到压测结果,dble 【后端挂有4个MySQL节点,1000数仓、1000线程并发】 : MySQL【 250数仓,250线程并发】 = 2.8 :1 左右。

当然,在理想情况下,两者的 tpmC 的值应该可以达到 4:1左右,可以看到,应该还是有可以提升的空间。除去必要的网络损耗,在其他 dble 内部可以优化的地方,我们的团队仍在努力尝试进行其他的优化,大家可以期待一下后续的版本表现。

至此,建议大家在使用 BenchmarkSQL 压测 dble ,使用可观测手段进行调优时,目前可主要针对前后端业务处理线程的数量进行调整(调低),调整的依据即为:

  • 理应保持前后端业务处理线程的使用率维持在一个比较高的水平,建议在95%左右
  • 通过dstat命令观测到dble所在机器的网络 IO 数值越高越好

此外,前后端 IO 线程数量和其他类型的线程数量可依据机器配置按照 dble 官方推荐值进行适配。另外需要注意的是,如果是多次进行压测,建议每次压测时都要将历史数据删除并重新进行数据准备,以免首次压测后造成数据上的污染,导致后续压测结果与首次压测结果偏差较大的问题。

你可能感兴趣的:(DBLE,BenchmarkSQL,dble)