第六期直播实践练习(可选):对一个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
:指定补仓时的开始值和截止值。如果导数据时发现某个仓库数据导入失败(大事务超时),您可以指定这个仓库重新导入。
修改建表语句
修改benchmarksql/run/sql.mysql/tableCreates.sql
create tabl