实践练习五（可选）：对 OceanBase 做性能测试

最新推荐文章于 2024-08-01 13:45:00 发布

张雨齐

最新推荐文章于 2024-08-01 13:45:00 发布

阅读量2.6k

点赞数

文章标签：服务器负载均衡云计算数据库

本文链接：https://blog.csdn.net/weixin_54238817/article/details/123172562

版权

OceanBase TPC-C 基准测试集群调优 OBProxy

关键词由CSDN通过智能技术生成

第六期直播实践练习（可选）：对一个OB集群（带 OBProxy）进行Benchamrk测试

环境准备

由于手上正好有7台物理机，在作业三中会使用OBD直接部署了2:2:2架构的OceanBase集群。这里直接拿来进行TPC-C测试。

机器信息如下：

机器类型	主机信息
IP	10.144.2.112,10.144.2.111,10.144.2.110,10.144.2.109, 10.144.2.108,10.144.2.107,10.144.2.107
网卡名	bond0
OS	CentOS Linux release 7.9.2009 (Core)
CPU	64
内存	256G，可用230G+
磁盘1	/data/1
磁盘2	data/2

机器划分如下：

角色	机器	备注
OBD	10.144.2.112	中控机，自动化安装部署软件
OBSERVER	10.144.2.111	OceanBase数据库，zone1
	10.144.2.110	OceanBase数据库，zone2
	10.144.2.109	OceanBase数据库，zone3
	10.144.2.108	OceanBase数据库，zone1
	10.144.2.107	OceanBase数据库，zone2
	10.144.2.106	OceanBase数据库，zone3
OBPROXY	10.144.2.111	OceanBase访问反向代理
	10.144.2.110	OceanBase访问反向代理
	10.144.2.109	OceanBase访问反向代理
	10.144.2.108	OceanBase访问反向代理
	10.144.2.107	OceanBase访问反向代理
	10.144.2.106	OceanBase访问反向代理
OBCLIENT	10.144.2.112	OceanBase命令行客户端

测试方案

使用 OBD 部署OceanBase 数据库集群。TPC-C 单独部署在一台机器上, 作为客户端的压力机器。
OceanBase 集群规模为 2：2：2。部署成功后，新建执行 TPC-C 测试的租户及用户：租户tpcc，用户benchmarksql。将租户的 primary_zone 设置为 RANDOM。RANDOM 表示新建表分区的 Leader 随机到这 6 台机器。

测试规格

warehouses=2000
loadWorkers=100
terminals=20
runMins=10
newOrderWeight=45
paymentWeight=43
orderStatusWeight=4
deliveryWeight=4
stockLevelWeight=4

安装 Benchmark SQL

按照以下步骤安装 Benchmark SQL：

下载 Benchmark SQL。

本次使用的是开源社区进行适配了mysql的benchmarksql。所以不包含修改源代码适配过程。
解压 Benchmark SQL。
```
unzip ./benchmarksql-5.0.zip
```

适配OceanBase

这里测试实验的是已经适配了mysql数据库的benchmarksql.

创建ob测试使用的配置文件

benchmarksql\run文件夹内创建prop.ob文件。

prop.ob中的参数说明：

JDBC 连接串：conn=jdbc:mysql:loadbalance://10.144.2.106:2883,10.144.2.107:2883,10.144.2.108:2883,10.144.2.109:2883,10.144.2.110:2883,10.144.2.111:2883/benchmark?rewriteBatchedStatements=true&allowMultiQueries=true&useLocalSessionState=true&useUnicode=true&characterEncoding=utf-8&socketTimeout=3000000
user=benchmarksql@tpcc
password=benchmarksql
rewriteBatchedStatements：

参数非常重要，会严重影响导数据效率，不可以忽略。
如果导数据较慢，可以用对应租户登录上去通过show full processlist检查是否开启。
new order事务中也用到了batch update，因此导数和benchmark阶段都需要开启。

并发数量（terminals）：200，mysql 租户配置下并发需要结合具体配置动态调整。
useLocalSessionState：是否使用autocommit，read_only和transaction isolation的内部值(jdbc端的本地值)，建议设置为true，如果设置为false，则需要发语句到远端请求，增加发送请求频次，影响性能。
warehouses/loadWorkers这两项用于设置压测数据量，可以适当调整。
numTerminals > 0 && numTerminals <= 10*numWarehouses，terminals的范围需要在这个区间内。
db=mysql 目前开源版只支持mysql租户，所以这里设置mysql
warehouses：指定仓库数。

通常仓库数就决定了这个性能测试理论上的成绩。如果期望测试结果越高，仓库数就不能太低。生产环境机器测试，建议 5000 仓库起步。如果机器配置较差，建议 100 仓起步。
loadWorkers：指定仓库数据加载时的并发。

如果机器配置很好，该值可以设置大一些，比如说 100 个。如果机器配置不高（尤其是内存），该值需要设置小一些，如 10 个并发。并发指定得过高，可能导致内存消耗太快，出现报错，导致数据加载前功尽弃。
terminals：指定性能压测时的并发数。

建议并发数不要高于仓库数 * 10 。否则，会有不必要的锁等待。在生产环境中，该并发数设置到 1000 就很高了。一般环境测试建议从 100 开始。
runMins：指定性能测试持续的时间。

时间越久，越能考验数据库的性能和稳定性。建议不要少于 10 分钟。生产环境中机器建议不少于 1 小时。
LoadStartW 和 LoadStopW：指定补仓时的开始值和截止值。

如果导数据时发现某个仓库数据导入失败（大事务超时），您可以指定这个仓库重新导入。