--- title: "OceanBase 系统性能问题排查最佳实践 - OceanBase 最佳实践 | OceanBase 文档中心" description: OceanBase 系统性能问题排查最佳实践 背景 在日常维护中，有时会遇到如下场景，而在这些场景中，可能会遇到排查繁琐，需要耗费大量的精力，但是问题的结论又不是很明确的情况。 这些场景包括但不仅限于此： 标准 benchmark 压测结果，跟内部发布的性能数据差异比较大。 低并发场景，性能不理想，耗时不符合预期。 … image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 # OceanBase 系统性能问题排查最佳实践 更新时间：2026-07-28 [编辑](https://github.com/oceanbase/best-practices-doc/edit/master/zh-CN/800.diagnostic/8000.best-practices-for-diagnosing-performance-issues.md) 适用产品： 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 报告](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001500502)。 - top -H -p {observer的pid} - 可以看到 observer 的所有线程。观察工作线程、IO、转储等线程的使用情况，判断 DB 端配置是否符合预期，是否到瓶颈。 - 特殊场景，分析各个工作线程的状态，也能协助定位一些性能问题。 上一篇 下一篇 ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线