oceanbase性能优化咨询

[北斗龙]

【 使用环境 】技术验证环境
【 组件 】oceanbase-ce、obproxy-ce
【 使用版本 】社区版本4.2.1.8，其他4.3.xxx版本已都使用过
【问题描述】

部署了一个单zone，三个oceanbase-ce的集群，如截图所示。
obproxy-ce代理转发至其中一个oceanbase-ce节点或者轮询到三个节点，qps合计均是4千到5千左右，很难高于6千。写入的效率既然没有一个mysql单机（16核32G）的写入效率高。请帮忙看下是部署架构的问题还是库表创建的问题？
业务表如下：。
CREATE TABLE bd_billing_road_item (
id bigint(20) NOT NULL COMMENT ‘明细id’,
vehicle_id bigint(20) NOT NULL COMMENT ‘车辆id’,
trip_id bigint(20) DEFAULT NULL COMMENT ‘关联行程id’,
traffic_id bigint(20) DEFAULT NULL COMMENT ‘通行记录ID’,
road_code varchar(50) DEFAULT NULL COMMENT ‘道路编码’,
section_code varchar(50) DEFAULT NULL COMMENT ‘路段编码’,
roadname varchar(100) DEFAULT NULL COMMENT ‘道路名称’,
road_type smallint(6) DEFAULT NULL COMMENT ‘收费道路类型’,
charge_type smallint(6) DEFAULT NULL COMMENT ‘是否收费’,
charge_distance decimal(15,2) DEFAULT NULL,
charge_amount decimal(15,2) DEFAULT NULL,
discount_amount decimal(15,2) DEFAULT NULL,
fee_basis smallint(6) DEFAULT NULL COMMENT ‘计费依据，1轨迹，2视频，3轨迹+视频’,
start_time datetime NOT NULL COMMENT ‘起点时间’,
end_time datetime DEFAULT NULL COMMENT ‘终点时间’,
create_time datetime NOT NULL COMMENT ‘创建时间’,
create_day date DEFAULT NULL COMMENT ‘创建日期’,
update_time datetime DEFAULT NULL COMMENT ‘更新时间’,
start_lon double(15,8) DEFAULT NULL COMMENT ‘起点经度’,
start_lat double(15,8) DEFAULT NULL COMMENT ‘起点纬度’,
start_address varchar(100) DEFAULT NULL COMMENT ‘起点地址’,
end_lon double(15,8) DEFAULT NULL COMMENT ‘终点经度’,
end_lat double(15,8) DEFAULT NULL COMMENT ‘终点纬度’,
end_address varchar(100) DEFAULT NULL COMMENT ‘终点地址’,
rate_code varchar(50) DEFAULT NULL COMMENT ‘费率编码’,
rate_value decimal(8,4) DEFAULT NULL,
discount_code varchar(50) DEFAULT NULL COMMENT ‘优惠编码’,
discount_type smallint(6) DEFAULT NULL COMMENT ‘优惠类型’,
deleted smallint(6) NOT NULL DEFAULT ‘0’ COMMENT ‘是否已经删除，0否 1是’,
PRIMARY KEY (id, vehicle_id, create_time, deleted),
KEY key_vehicle_id (vehicle_id),
KEY key_traffic_id (traffic_id)
) DEFAULT CHARSET = utf8mb4 COMPRESSION = ‘none’ COMMENT = ‘道路计费明细表’
partition by range(to_days(create_time))
SUBPARTITION BY KEY(vehicle_id) SUBPARTITIONS 3
(
partition p20241126 values less than (739581),
partition p20241127 values less than (739582),
partition p20241128 values less than (739583),
partition p20241129 values less than (739584),
partition p20241130 values less than (739585),
partition p20241201 values less than (739586),
partition p20241202 values less than (739587),
partition p20241203 values less than (739588),
partition p20241204 values less than (739589),
partition p20241205 values less than (739590),
partition p20241206 values less than (739591),
partition p20241207 values less than (739592),
partition p20241208 values less than (739593),
partition p20241209 values less than (739594),
partition p20241210 values less than (739595),
partition p20241211 values less than (739596),
partition p20241212 values less than (739597),
partition p20241213 values less than (739598),
partition p20241214 values less than (739599),
partition p20241215 values less than (739600),
partition p20241216 values less than (739601),
partition p20241217 values less than (739602),
partition p20241218 values less than (739603),
partition p20241219 values less than (739604),
partition p20241220 values less than (739605),
partition p20241221 values less than (739606),
partition p20241222 values less than (739607),
partition p20241223 values less than (739608),
partition p20241224 values less than (739609),
partition p20241225 values less than (739610),
partition p20241226 values less than (739611),
partition p20241227 values less than (739612),
partition p20241228 values less than (739613),
partition p20241229 values less than (739614),
partition p20241230 values less than (739615),
partition p20241231 values less than (739616)
);

CREATE TABLE bd_billing_traffic_record (
id bigint(20) NOT NULL COMMENT ‘id’,
vehicle_id bigint(20) NOT NULL COMMENT ‘车辆id’,
charge_distance decimal(15,2) DEFAULT NULL,
charge_amount decimal(15,2) DEFAULT NULL,
discount_amount decimal(15,2) DEFAULT NULL,
actual_amount decimal(15,2) DEFAULT NULL,
year_mileage bigint(20) DEFAULT NULL,
start_time datetime NOT NULL COMMENT ‘起点时间’,
end_time datetime DEFAULT NULL COMMENT ‘终点时间’,
create_time datetime NOT NULL COMMENT ‘创建时间’,
create_day date DEFAULT NULL COMMENT ‘创建日期’,
update_time datetime DEFAULT NULL COMMENT ‘更新时间’,
start_lon double(15,8) DEFAULT NULL COMMENT ‘起点经度’,
start_lat double(15,8) DEFAULT NULL COMMENT ‘起点纬度’,
start_address varchar(100) DEFAULT NULL COMMENT ‘起点地址’,
end_lon double(15,8) DEFAULT NULL COMMENT ‘终点经度’,
end_lat double(15,8) DEFAULT NULL COMMENT ‘终点纬度’,
end_address varchar(100) DEFAULT NULL COMMENT ‘终点地址’,
settlement_id bigint(20) DEFAULT NULL COMMENT ‘账单id’,
deleted smallint(6) NOT NULL DEFAULT ‘0’ COMMENT ‘是否已经删除，0否 1是’,
PRIMARY KEY (id, vehicle_id, create_time, deleted),
KEY key_vehicle_id (vehicle_id),
KEY key_settlement_id (settlement_id)
) DEFAULT CHARSET = utf8mb4 COMPRESSION = ‘none’ COMMENT = ‘通行记录’
partition by range(to_days(create_time))
SUBPARTITION BY KEY(vehicle_id) SUBPARTITIONS 3
(
partition p20241126 values less than (739581),
partition p20241127 values less than (739582),
partition p20241128 values less than (739583),
partition p20241129 values less than (739584),
partition p20241130 values less than (739585),
partition p20241201 values less than (739586),
partition p20241202 values less than (739587),
partition p20241203 values less than (739588),
partition p20241204 values less than (739589),
partition p20241205 values less than (739590),
partition p20241206 values less than (739591),
partition p20241207 values less than (739592),
partition p20241208 values less than (739593),
partition p20241209 values less than (739594),
partition p20241210 values less than (739595),
partition p20241211 values less than (739596),
partition p20241212 values less than (739597),
partition p20241213 values less than (739598),
partition p20241214 values less than (739599),
partition p20241215 values less than (739600),
partition p20241216 values less than (739601),
partition p20241217 values less than (739602),
partition p20241218 values less than (739603),
partition p20241219 values less than (739604),
partition p20241220 values less than (739605),
partition p20241221 values less than (739606),
partition p20241222 values less than (739607),
partition p20241223 values less than (739608),
partition p20241224 values less than (739609),
partition p20241225 values less than (739610),
partition p20241226 values less than (739611),
partition p20241227 values less than (739612),
partition p20241228 values less than (739613),
partition p20241229 values less than (739614),
partition p20241230 values less than (739615),
partition p20241231 values less than (739616)
);
性能监控：

[一夕]

zone有打散嘛

[北斗龙]

没太明白你的意思。
原先部署了三个zone，自动三个副本，写入效率非常慢。
改为了一个zone，zone包含三个oceanbase-ce节点，建表语句如上图截图。
以及ALTER PROXYCONFIG SET target_db_server = ‘10.233.200.26:2881,10.233.200.27:2881,10.233.200.29:2881’; obproxy-ce设置了轮询到三个oceanbase-ce节点。

[Livedba]

按1-1-1模式部署，三个zone，每个zone一个obsever，之后设置primary zone 为单zone：zone1;zon2;zone3; 再跑一下压测看看

[淇铭]

建议你先用sysbench压测 可以压测出一些问题 在进行调优
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000218151

[北斗龙]

按1-1-1这种模式尝试过，这种模式写入效率更低，写入效率不如单个zone，3个oceanbase-ce，既1-3模式。

[Livedba]

按照1-1-1架构搭建并设置下primary_zone，调整一下以下参数在跑sysbench压测看看呢

ob_sql_work_area_percentage = 20
max_allowed_packet = 1073741824
writing_throttling_trigger_percentage=90
freeze_trigger_percentage=70

[北斗龙]

这些都试过，刚也再重新弄了一下，还是写入效率不高。还没有1-3模式写入效率高。是不是这个建表语句有什么问题。
CREATE TABLE bd_billing_road_item (
id bigint(20) NOT NULL COMMENT ‘明细id’,
vehicle_id bigint(20) NOT NULL COMMENT ‘车辆id’,
trip_id bigint(20) DEFAULT NULL COMMENT ‘关联行程id’,
traffic_id bigint(20) DEFAULT NULL COMMENT ‘通行记录ID’,
road_code varchar(50) DEFAULT NULL COMMENT ‘道路编码’,
section_code varchar(50) DEFAULT NULL COMMENT ‘路段编码’,
roadname varchar(100) DEFAULT NULL COMMENT ‘道路名称’,
road_type smallint(6) DEFAULT NULL COMMENT ‘收费道路类型’,
charge_type smallint(6) DEFAULT NULL COMMENT ‘是否收费’,
charge_distance decimal(15,2) DEFAULT NULL,
charge_amount decimal(15,2) DEFAULT NULL,
discount_amount decimal(15,2) DEFAULT NULL,
fee_basis smallint(6) DEFAULT NULL COMMENT ‘计费依据，1轨迹，2视频，3轨迹+视频’,
start_time datetime NOT NULL COMMENT ‘起点时间’,
end_time datetime DEFAULT NULL COMMENT ‘终点时间’,
create_time datetime NOT NULL COMMENT ‘创建时间’,
create_day date DEFAULT NULL COMMENT ‘创建日期’,
update_time datetime DEFAULT NULL COMMENT ‘更新时间’,
start_lon double(15,8) DEFAULT NULL COMMENT ‘起点经度’,
start_lat double(15,8) DEFAULT NULL COMMENT ‘起点纬度’,
start_address varchar(100) DEFAULT NULL COMMENT ‘起点地址’,
end_lon double(15,8) DEFAULT NULL COMMENT ‘终点经度’,
end_lat double(15,8) DEFAULT NULL COMMENT ‘终点纬度’,
end_address varchar(100) DEFAULT NULL COMMENT ‘终点地址’,
rate_code varchar(50) DEFAULT NULL COMMENT ‘费率编码’,
rate_value decimal(8,4) DEFAULT NULL,
discount_code varchar(50) DEFAULT NULL COMMENT ‘优惠编码’,
discount_type smallint(6) DEFAULT NULL COMMENT ‘优惠类型’,
deleted smallint(6) NOT NULL DEFAULT ‘0’ COMMENT ‘是否已经删除，0否 1是’,
PRIMARY KEY (id, vehicle_id, create_time, deleted),
KEY key_vehicle_id (vehicle_id),
KEY key_traffic_id (traffic_id)
) DEFAULT CHARSET = utf8mb4 COMPRESSION = ‘none’ COMMENT = ‘道路计费明细表’
partition by range(to_days(create_time))
SUBPARTITION BY KEY(vehicle_id) SUBPARTITIONS 3
(
partition p20241126 values less than (739581),
partition p20241127 values less than (739582),
partition p20241128 values less than (739583),
partition p20241129 values less than (739584),
partition p20241130 values less than (739585),
partition p20241201 values less than (739586),
partition p20241202 values less than (739587),
partition p20241203 values less than (739588),
partition p20241204 values less than (739589),
partition p20241205 values less than (739590),
partition p20241206 values less than (739591),
partition p20241207 values less than (739592),
partition p20241208 values less than (739593),
partition p20241209 values less than (739594),
partition p20241210 values less than (739595),
partition p20241211 values less than (739596),
partition p20241212 values less than (739597),
partition p20241213 values less than (739598),
partition p20241214 values less than (739599),
partition p20241215 values less than (739600),
partition p20241216 values less than (739601),
partition p20241217 values less than (739602),
partition p20241218 values less than (739603),
partition p20241219 values less than (739604),
partition p20241220 values less than (739605),
partition p20241221 values less than (739606),
partition p20241222 values less than (739607),
partition p20241223 values less than (739608),
partition p20241224 values less than (739609),
partition p20241225 values less than (739610),
partition p20241226 values less than (739611),
partition p20241227 values less than (739612),
partition p20241228 values less than (739613),
partition p20241229 values less than (739614),
partition p20241230 values less than (739615),
partition p20241231 values less than (739616)
);

[北斗龙]

效率明显比1-3模式还低。

[淇铭]

这些都是压测的数据么？压测过程是否出现什么问题？

[北斗龙]

没有使用TPC的样例做压测，我们直接使用我们的业务系统产生的业务数据写入，启动了几十个业务系统节点写入数据。同样的业务数据和服务节点，同时写入mysql和oceanbase做对比。oceanbase的三个节点服务器的配置合计高于mysql单机的三四倍，但写入效率依然没有mysql单机好。性能上依旧不理想。我不太相信性能会那么差，应该是我们使用的问题，但各种模式以及配置都尝试了，太不理想了。

[淇铭]

我们建议 还是使用sysbench做一次压测 压测可以可以看出是不是哪些瓶颈 主要mysql你们使用时间久 参数的调整 cpu io等等都达到了理想值 ob是你们刚使用的 有些搭配 服务器的优化参数 数据磁盘和日志磁盘是否同盘 磁盘的iops是多少 数据库的tps qps 分布式数据库对网络的要求也高 网络的延迟

压测首先要保证observer节点cpu跑满：

1. 先查看租户cpu和内存是否足够：
   select * from oceanbase.dba_ob_tenants;
2. 通过top查看cpu使用率是否达到租户cpu和机器上限，如果没有，top -H看看子线程是否打满；
3. 如果某些子线程占用100%，那么可能是该线程成为瓶颈；
4. 如果没有线程是瓶颈，那很可能是发送到observer的请求压力不够，比如obproxy的瓶颈（可以尝试直连observer的leader测试）；
5. 也可能是硬件瓶颈，比如网卡虽然带宽很高，但网卡队列数量过低，可以通过以下命令增加：sudo ethtool -L eth0 combined 4；或者磁盘性能不足，但一般高性能SSD就够了；
   observer的CPU跑满之后，再考虑sysbench的参数是否合理，observer集群的配置和租户的配置是否合适。
   https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000749129

如果客户端给的压力不够，建议直连leader测一下试试。同时检查一下sysbench客户端和observer所在机器的cpu核数：lscpu；网卡队列数量：ethtool -l eth0（改下网卡名字）

leader的IP地址可以通过日志流的位置判断：select * from __all_virtual_ls_info where tenant_id = 1002 and ls_state=‘leader’;

[obpilot]

三个表都是按天分区的分区表，测试记录的分区列是时间都是同一天的话，自然只会插入到一个具体的分区中，并不是想象的三个节点同时插入。
除非这三个表对应的分区恰好是在三个节点上。即使如此，也还要看测试逻辑（事务和sql怎么写的）。

OB 的分布式跟 TiDB的分布式还是有点区别，区别就在于OB的分布式里有业务逻辑。所以你这里业务测试逻辑很重要。

为什么建议用 sysbench 呢？因为 sysbench 没有逻辑，纯粹随机写入（id 或随机或自增），所以分布式能发挥效果。

[北斗龙]

@北斗龙

SUBPARTITION BY KEY(vehicle_id) SUBPARTITIONS 3

加一个二级分区SUBPARTITION BY KEY(vehicle_id) SUBPARTITIONS 3，这样是可以打在三个节点上吧？
还有1-1的模式，三个zone，不是三个副本，不管怎么分区都是只写到一个zone中吧？其他两个zone都是同步数据吧？

[obpilot]

恩，是的。可以试试。
然后你可以先发一下所有分区的位置。

SELECT /*+ read_consistency(weak) query_timeout(1000000000) */ t1.tenant_id, t1.database_name,  round(sum(t2.required_size)/1024/1024/1024) required_size_gb, count(*) cnt
FROM oceanbase.CDB_OB_TABLE_LOCATIONS t1 
  JOIN oceanbase.cdb_ob_tablet_replicas t2 ON (t1.tenant_id=t2.tenant_id and t1.tablet_id=t2.tablet_id AND t1.ls_id=t2.ls_id and t1.svr_ip=t2.svr_ip and t1.SVR_PORT=t2.svr_port )
WHERE t1.tenant_id in (1002) and t1.ROLE='LEADER'  
GROUP BY t1.tenant_id, t1.database_name
;

为了简单，不如你把那个 range 分区去掉吧，只看 hash分区效果。

[北斗龙]

range 分区去掉，替换成hash（vehicle_id）效率上没什么变化，这个都试过。

[obpilot]

那就不符合预期。还要继续找原因。
一个是尽量将测试简单。只测试一个表，并且把表的索引先都删除掉。只用hash分区。然后再在随后的测试中逐渐增加索引和表，看看表现发展转折的点是什么时候。
二个要看看集群和租户的参数设置。以及集群和租户的资源规格等。
建议用 obdiag 收集一份完整的集群信息 发一下看看。