求助：OceanBase 节点众多，该用什么指标精准判断性能瓶颈？

OceanBase 技术问题
#1

以前做 Oracle、MySQL 单机库的时候，判断瓶颈很直接：CPU 跑满、内存打满、IO wait 飙升、等待事件扎堆，基本就能确认数据库到瓶颈了。但迁到 OceanBase 分布式架构之后，发现这套老方法论有点失灵了，主要卡在两个点：

  1. 单节点指标很容易“谎报军情”：某台 OBServer 的 CPU 飙到 70%+，可能只是运维手工跑了个统计查询或者局部热点，集群整体其实还远没到瓶颈；反过来，所有 OBServer CPU 都很低，业务侧却可能已经出现明显延迟（比如 OBProxy 排队、clog 同步延迟、租户资源限制等）。

  2. 组件多、等待事件也多，很难全局判断：OBServer、OBProxy、OCP、RootService 各有各的监控，OceanBase 虽然等待事件很丰富（V$SESSION_WAIT 等），但在多租户、多节点环境下事件量巨大，OCP 监控面板密密麻麻。日常巡检到底该盯哪几个，才能一眼看出“集群整体是不是真到了瓶颈”？

想请教大家三个问题：

  1. 日常判断集群是否存在性能瓶颈，你们最核心看哪些指标？（是看租户级的 SQL RT、事务延迟、MemStore 使用率，还是机器层的 CPU/IO/网络，或者等待事件排名？）
  2. 哪些指标你们会配成核心告警？（除了节点宕机、磁盘满这种硬件级告警，性能瓶颈类的告警大家一般怎么配？单节点 CPU / 内存使用率还会作为核心告警吗？在 OB 多租户场景下，会不会更关注租户级的资源使用百分比？）
  3. 告警阈值是统一标准，还是按集群业务属性单独调？（比如核心交易系统和大数据批处理集群，你们会差异化设定 CPU、日志盘使用率等阈值吗？）

感谢各位前辈指点！期待实战经验分享 :muscle:

3 个赞
#3

@论坛小助手

#4

OceanBase 性能瓶颈判断与监控策略

迁移到分布式架构如OceanBase后，性能瓶颈的识别确实变得更加复杂。基于您提出的问题，这里提供一些基于OceanBase特性的建议，帮助更准确地判断集群是否存在性能瓶颈及如何配置有效的告警。

1. 核心指标选择

在OceanBase中，要全面评估集群性能状况，需要从多个维度综合考虑。以下是一些关键指标：

  • 租户级指标:

    • SQL RT（响应时间）: 监控特定租户下所有SQL查询的平均响应时间，过长可能指示存在执行计划不佳或资源争用等问题。
    • 事务延迟: 分析事务完成时间，特别是对于在线事务处理(OLTP)场景尤为重要。
    • MemStore使用率: MemStore是内存中的临时存储区，用于提高写入性能。高使用率可能表示内存不足或者写操作过于频繁。

  • 机器层面:

    • CPU利用率: 虽然单个节点的高CPU并不一定代表整体系统面临压力，但持续高CPU可能是某些热点问题的表现。
    • I/O等待: 长时间的I/O等待可能揭示磁盘访问瓶颈。
    • 网络流量和延迟: 网络拥塞也是常见的性能瓶颈之一。

  • 全局事件分析:

    • 请求等待队列耗时：文档片段4 提到了这个指标可以帮助理解整个集群范围内请求处理效率。
    • 进程CPU使用率：文档片段10 提供了有关查询进程CPU使用率的方法，这有助于识别哪些进程消耗了过多资源。

2. 核心告警设置

  • 性能相关告警：

    • 租户级的SQL RT过高、事务延迟超限时应触发告警。
    • MemStore使用率接近上限时也应设置告警，以防止内存溢出风险。
    • 对于单节点的CPU/内存使用率，虽然不再作为主要性能瓶颈标志，但仍需保持监测并设置合理的阈值，比如当连续一段时间超过80%时触发告警。

  • 系统稳定性告警：

    • OBProxy排队现象明显增加。
    • CLOG同步延迟超过预设阈值，影响数据一致性。
    • 日志盘使用率逼近满载状态等。

3. 告警阈值调整

  • 阈值设定应根据实际业务需求而定，并非一刀切。例如：
    • 对于核心交易系统而言，任何可能导致延迟的因素都应被密切监控，因此这类系统的告警阈值可以设置得更为严格。
    • 对于大数据批处理任务，则可能对短暂的性能下降容忍度更高，相应地，其告警条件可以相对宽松一些。

总之，在多租户环境中特别要注意租户间的资源分配公平性以及各自对资源的需求差异。利用OCP提供的丰富可视化工具(文档片段6)来定期检查各类指标的趋势变化，及时发现潜在问题所在。同时，结合业务特性灵活调整监控策略，才能更有效地维护OceanBase集群的稳定性和高效性。

具体信息可参考以下文档:

  1. SQL 性能问题的典型场景和排查思路
  2. ob_tenant500_mem_hold_percent_over_threshold OB 500 租户内存占用率超限
  3. ob_tenant500_mem_hold_over_threshold OB 500 租户的占用内存大小超限
  4. 请求等待队列耗时
  5. ob_cpu_assigned_percent_over_threshold OB 已经分配给租户的 CPU 占比超限
  6. 集群管理
  7. ob_cluster_sync_delay_time_too_long 主备集群同步延迟过大告警
  8. 监控告警
  9. ob_host_mem_percent_over_threshold OB 服务器内存使用率超限
  10. 进程 CPU 使用率
1 个赞
#5

分布式数据库还是很复杂的

#6

学习了，分布式数据库要判断整体性能瓶颈确实要综合考虑从集群到操作系统等多方面因素