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

背景介绍

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

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

配置建议

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

后端连接数

日志级别

隔离级别

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

dble 的配置

MySQL 的配置

观测手段

系统资源观测工具

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

dble 侧观测手段

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

  

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

2)完成解析

3)完成路由分配

4)从数据库回收结果

5)后置处理

6)反馈处理

• 查看线程使用率

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

压测经验

关于 dstat

关于查询耗时统计

关于 show 命令

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

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

• 前后端 IO 线程 及 complexExecutor、writeToBackendExecutor的数量对于压测 tpmC 的值没有明显影响

• 对于tpmC值影响最大的为前后端业务处理线程数量，且前后端业务处理线程使用率与 tpmC的值正向相关，即前后端业务处理线程的线程使用率越高，tpmC 的值越高

• dble 所在机器的网络 IO 与 tpmC 的值正向相关，即网络 IO 越高，tpmC的值越高【通过观察 dstat 的结果而得】

• 前后端业务处理线程数量调整，对于 dble 所在机器的网络 IO 与前后端业务处理线程使用率影响一致，即前后端业务处理线程数量下调， 网络 IO 上升、线程使用率上升，且 tpmC 值越高

总结

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

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

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

本文关键字：#BenchmarkSQL# #dble#