OceanBase高可用架构下的性能瓶颈

OceanBase 技术问题
#1

【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】
【 使用版本 】
【问题描述】 OceanBase高可用架构下的性能瓶颈​
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

2 个赞
#3

配置ODP的KeepAlive探活机制，及时剔除异常节点。

1 个赞
#4

根据您提供的问题描述，以下是关于 OceanBase 高可用架构下性能瓶颈的分析和解答。由于您未提供具体的使用环境、组件版本及复现路径等信息，以下内容基于文档库中的通用信息进行总结。

1. OceanBase 高可用架构概述

根据文档《高可用架构概述》中的信息：

  • OceanBase 数据库采用 Shared-Nothing 的分布式架构，每个数据节点（OBServer 节点）都是对等的。
  • 数据分布在一个 Zone 的多个数据节点上，其他 Zone 存放多个数据副本。例如，一个典型的三副本架构中，每个 Zone 存放一份数据副本。
  • 高可用架构通过多副本容灾（基于 Paxos 协议）实现少数派故障时 RPO=0 和 RTO<8s 的能力。

高可用部署方案：

  • 社区版支持四种高可用部署方案，包括同城三机房三副本、三地五中心五副本、同城两机房“主-备”部署和两地三中心“主-备”部署。
  • 注意：社区版不支持仲裁服务。

2. 高可用架构下的性能瓶颈分析

在高可用架构下，性能瓶颈可能来源于以下几个方面：

(1) OBServer 端性能瓶颈

根据文档《SQL 性能问题的典型场景和排查思路》中的信息：

  • 运行态问题：可能是优化器生成了非最优执行计划，导致 SQL 请求需要扫描大量数据；或者计划缓存命中率不高，导致额外的编译时间。
  • 阻塞态问题：工作线程可能在等待 I/O、网络或临界区资源，这通常与系统并发瓶颈有关。
  • 排查方法：通过 sql_audit 表分析 OBServer 行为，定位具体瓶颈点。

(2) 路由高可用因素

根据文档《ODP SQL 路由原理》中的信息：

  • ODP 在发现 OBServer 节点故障后，会将该节点加入黑名单，并选择健康节点进行路由。
  • 如果路由策略设计不合理，可能会导致负载不均衡或频繁重试，从而影响性能。

(3) 租户资源争用

根据文档《租户请求队列积压》中的信息：

  • 当集群租户请求量升高或存在复杂查询时，CPU 资源不足会导致队列请求积压。
  • 主要现象为 SQL 响应时间变长，处理响应速度变慢。

(4) 多副本同步开销

根据文档《高可用概述 → 多副本容灾》中的信息：

  • 多副本容灾技术通过事务日志持久化并在多个副本之间同步日志数据。
  • 如果网络延迟较高或副本间同步效率低下，可能会导致写入性能下降。

3. 性能优化建议

结合上述分析，以下是一些性能优化建议：

(1) 优化 SQL 执行计划

  • 检查是否存在非最优执行计划，调整索引或 SQL 语句以减少扫描量。
  • 提高计划缓存命中率，避免重复编译。

(2) 调整数据库参数

根据文档《OceanBase 数据库性能的影响因素 → 数据库参数调优 → OLAP 场景》中的代码示例：

# 设置 SQL 工作区内存占整个租户内存百分比
SET GLOBAL ob_sql_work_area_percentage = 80;

# 设置 SQL 最大执行时间
SET GLOBAL ob_query_timeout = 36000000000;

# 设置事务超时时间
SET GLOBAL ob_trx_timeout = 36000000000;

# 设置最大网络包的大小
SET GLOBAL max_allowed_packet = 67108864;

# 租户在每个节点上可申请的并行执行线程数量
SET GLOBAL parallel_servers_target = 624;

(3) 优化路由策略

  • 确保 ODP 能够实时感知 OBServer 节点状态和数据分布。
  • 避免因路由不合理导致的负载不均衡或频繁重试。

(4) 提升硬件资源配置

  • 根据文档《OceanBase 数据库性能的影响因素》中的信息，操作系统参数的调整和软硬件资源环境的合理配置对性能有直接影响。
  • 增加 CPU、内存或网络带宽，缓解资源争用问题。

(5) 监控与诊断

  • 使用 OceanBase 内置的监控工具（如 OCP 或 obdiag）收集诊断信息，定位具体瓶颈点。
  • 定期检查 sql_audit 表，分析慢查询和性能异常。

4. 结论

OceanBase 高可用架构下的性能瓶颈可能来源于 OBServer 端行为、路由策略、租户资源争用或多副本同步开销等多个方面。通过优化 SQL 执行计划、调整数据库参数、改进路由策略以及提升硬件资源配置，可以有效缓解性能瓶颈。

如果问题仍未解决，建议使用 OceanBase 敏捷诊断工具 obdiag 收集诊断信息，并联系 OceanBase 技术支持团队获取进一步帮助。

更多信息请查看:

  1. SQL 性能问题的典型场景和排查思路
  2. OceanBase 数据库性能的影响因素
  3. ODP SQL 路由原理
  4. 高可用架构概述
  5. 部署生产环境
  6. 租户请求队列积压
  7. 高可用概述
4 个赞
#5

学习到了，可以多关注

2 个赞
#6

业务量比较小,还没有碰到过这种情况

2 个赞