OceanBase 系统性能问题排查最佳实践

背景

在日常维护中，有时会遇到如下场景，而在这些场景中，可能会遇到排查繁琐，需要耗费大量的精力，但是问题的结论又不是很明确的情况。

这些场景包括但不仅限于此：

• 标准 benchmark 压测结果，跟内部发布的性能数据差异比较大。
• 低并发场景，性能不理想，耗时不符合预期。
• 压测结果看起来还好，但不确定是否为 OB 的极限能力。
• CPU 使用率很高，但 QPS 很低，性能较差。
• CPU 使用率低，链路延迟也比较小，整体高并发压测，QPS 较低。
• 多机部署的场景，机器负载不均衡。

影响性能的因素

部署问题

• 硬件部署

  • ODP 和 OBServer 混合部署可能导致资源开销大，特别是在高并发压测中。
  • 压测客户端、负载均衡器与 ODP 的跨机房部署会增加延迟。
  • LB、ODP 所在机器的连接数和性能规格偏小容易成为瓶颈。
  • 数据盘与日志盘的共享会影响高并发写入时的性能。

• 事务模型

  • 远程执行与分布式事务提交会导致性能下降。
  • 单条 SQL 若无法裁剪分区，将会导致全分区扫描浪费资源。
  • ODP 无法正确路由请求，导致请求随机分发。

计划不优 & 关键优化缺失

• 执行计划：多级 nlj 大大影响计划执行效率，不支持 batch rescan。
• 数据模型：合理的数据模型设计对性能至关重要，例如：合理使用大小账号、buffer 表等。
• 索引策略：合理使用索引，避免不必要的随机写入和全表扫描。

系统问题

• 系统热点：DB 内部实现可能导致系统热点，增加 CPU 开销。
• 内核配置：系统的 Kernel 配置问题会严重影响性能。
• IO 性能：磁盘 IOPS、读写带宽、网络带宽的不足都会影响性能。

排查思路

重视诊断原则

• 集群部署

  • 对于有条件的业务，希望 ODP 不要跟 OBServer 混部，极限场景下，ODP 会影响一定的性能。
  • 一般来讲，同机房延迟 50-170us 左右，同城双机房延迟 1.5ms 左右，杭州到上海延迟 5ms，上海到深圳延迟 25ms，具体延迟情况跟实际网络环境有关系。
  • 高性能压测，建议去掉 ODP，sysbench point select 场景。

• 扩展性

  • 扩展性测试，如果要达到线性扩展的能力，需要扩展过程中，链路组件、事务模型、DB 内核各个模块等都需要具备线性扩展的能力，任何一环成为瓶颈，线性扩展都会受到影响。

    • 事务需要单机执行，SQL 不能有远程 RPC。
    • 客户端、ODP 等所在物理机软、硬件资源都必须具备线性扩展的能力。

  • 密切关注 OCP 里面 TOP SQL 的大图，要对 rpc_count >= 1、partition_count > 1、非 Local 计划的 SQL 进行密切关注。根据 CPU 整体使用率来进行倒排，需要梳理每一条 SQL 的合理性。

• 单并发压测冒烟

  • 对于简单场景，但耗时较长的业务 SQL，最简单的方式是做单并发压测，统计从应用服务器->LB->ODP->Ob Leader 整条链路下的延迟情况，分析关键瓶颈点。

• 系统环境数据

  • 高并发压测，sys cpu 不能超过 15%，超过这个阈值，需要分析。
  • 高并发压测，需要确保 cpu 跑满，对于跑不满的场景，需要分析。
  • 数据、日志盘 IO rt，tcp 的重传率等都需要确保一个合理的范围。

• OCP 诊断监控使用举例

  • TOP SQL：进入 OAS 的 TOP SQL 界面，某条 SQL 凡是具备如下特征的，需要关注、分析、确认是否有风险：

    • 表扫描是否为 1。

    • RPC 的数量是否大于 0。

    • 访问的分区数是否大于 1。

    • 简单 SQL（返回行少量、基于主键、索引等）的执行是否大于 1ms。

  • Slow Query：

    • 进入 OAS 的 Slow Query 界面，分别按照总数据库耗时、最大响应时间两个维度做倒排，分别关注两类 SQL：

      • 数据库总耗时 TOP N 高的 SQL。

      • 最大响应时间 TOP N 高的 SQL。

  • 对上述两类 SQL 需要做如下精细化的 check：

    • 确保 TOP SQL 里面 4 项检查是否符合预期。
    • 确保计划是否正确。
    • 是否存在并行读大于 1 的 SQL。

排查工具

• OCP

  • 关注整个业务的 SQL 大图，分析存在 rpc、多分区访问、存在读盘、计划异常的 SQL。

  • 关注 CPU 使用率、数据和 CLOG io rt、SQL RT 和均衡性。

• ASH（Active Session History）

  • 4.x 增加了更加丰富的采集信息，可以通过 ASH Report 的方式针对单个 SQL 生成详细的监控数据；详细步骤，请参考文档 生成 ASH 报告。

• top -H -p {observer的pid}

  • 可以看到 observer 的所有线程。观察工作线程、IO、转储等线程的使用情况，判断 DB 端配置是否符合预期，是否到瓶颈。

  • 特殊场景，分析各个工作线程的状态，也能协助定位一些性能问题。