在数据库运维中，性能优化对保障业务稳定运行起着关键作用。然而，日常运维中常常会遇到各种性能问题。这些问题排查难度大，需要耗费大量的精力，最终得出的结论有时还不是很明确，给运维工作带来了巨大的挑战。
这些场景包括但不限于以下几个方面：
👉 标准 Benchmark 压测结果，和内部发布的性能数据差异比较大。
👉 低并发场景下，性能不理想，耗时不符合预期。
👉 压测结果看起来还好，但不确定是否为 OceanBase 的极限能力。
👉 CPU 使用率很高，但 QPS 很低，性能较差。
👉 CPU 使用率低，链路延迟也比较小，整体高并发压测，QPS 较低。
👉 多机部署的场景，机器负载不均衡。
为了更好地应对这些问题，深入剖析性能影响因素，掌握科学的排查思路与实用的排查工具就显得尤为必要。本文将全面深入地探讨这些关键内容，助力运维人员提升数据库性能优化的能力。
一、影响性能的因素
影响性能的因素主要有三个方面，即部署问题、计划不优 & 关键优化缺失以及系统问题。
（一）部署问题
1、硬件部署
👉 ODP 和 OBServer 混合部署可能导致资源开销大，特别是在高并发压测中。
👉 压测客户端、负载均衡器与 ODP 的跨机房部署会增加延迟。
👉 LB、ODP 所在机器的连接数和性能规格偏小容易成为瓶颈。
👉 数据盘与日志盘的共享会影响高并发写入时的性能。
2、事务模型
👉 远程执行与分布式事务提交会导致性能下降。
👉 单条 SQL 若无法裁剪分区，将会导致全分区扫描浪费资源。
👉 ODP 无法正确路由请求，导致请求随机分发。
（二）计划不优 & 关键优化缺失
👉 执行计划：多级 NLJ 大大影响计划执行效率，不支持 Batch Rescan。
👉 数据模型：合理的数据模型设计对性能至关重要，例如：合理使用大小账号、Buffer 表等。
👉 索引策略：合理使用索引，避免不必要的随机写入和全表扫描。
（三）系统问题
👉 系统热点：DB 内部实现可能导致系统热点，增加 CPU 开销。
👉 内核配置：系统的 Kernel 配置问题会严重影响性能。
👉 IO 性能：磁盘 IOPS、读写带宽、网络带宽的不足都会影响性能。
二、排查思路
排查思路主要遵循重视诊断原则，重点排查集群部署、扩展性测试、单并发压测冒烟、系统环境数据分析以及 OCP 诊断监控使用等多个关键方面。
（一）集群部署
👉 对于有条件的业务，希望 ODP 不要跟 OBServer 混部，极限场景下，ODP 会影响一定的性能。
👉 一般来讲，同机房延迟 50-170us 左右，同城双机房延迟 1.5ms 左右，杭州到上海延迟 5ms，上海到深圳延迟 25ms，具体延迟情况跟实际网络环境有关系。
👉 高性能压测建议去掉 ODP，Sysbench Point Select 场景。
（二）扩展性
1、扩展性测试，如果要达到线性扩展的能力，需要在扩展过程中，链路组件、事务模型、DB 内核各个模块等都具备线性扩展的能力，任何一环成为瓶颈，线性扩展都会受到影响。
👉 事务需要单机执行，SQL 不能有远程 RPC。
👉 客户端、ODP 等所在物理机的软、硬件资源都必须具备线性扩展的能力。
2、密切关注 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 诊断监控使用举例
1、TOP SQL：进入 OAS 的 TOP SQL 界面，某条 SQL 凡是具备如下特征的，需要关注、分析，确认是否有风险：
👉 表扫描是否为 1。
👉 RPC 的数量是否大于 0。
👉 访问的分区数是否大于 1。
👉 简单 SQL（返回行少量、基于主键、索引等）的执行是否大于 1ms。
2、Slow Query：进入 OAS 的 Slow Query 界面，分别按照总数据库耗时、最大响应时间两个维度做倒排，分别关注两类 SQL：
👉 数据库总耗时 TOP N 高的 SQL。
👉 最大响应时间 TOP N 高的 SQL。
3、对上述两类 SQL 需要做如下精细化的 Check：
👉 确保 TOP SQL 里面 4 项检查是否符合预期。
👉 确保计划是否正确。
👉 是否存在并行读大于 1 的 SQL。
三、排查工具
（一）OCP
👉 关注整个业务的 SQL 大图，分析存在 RPC、多分区访问、存在读盘、计划异常的 SQL。
👉 关注 CPU 使用率、数据和 CLOG IO RT、SQL RT 和均衡性。
（二）ASH（Active Session History）
OceanBase 4.x 版本增加了更加丰富的采集信息，可以通过 ASH Report 的方式针对单个 SQL 生成详细的监控数据。详细步骤，可以通过下方链接或二维码，参考文档 生成 ASH 报告。
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001500502
（三）Top -H -P {OBServer 的 PID }
👉 可以看到 OBServer 的所有线程。观察工作线程、IO、转储等线程的使用情况，判断 DB 端配置是否符合预期，是否到瓶颈。
👉 特殊场景，分析各个工作线程的状态，也能协助定位一些性能问题。
数据库性能问题的排查与优化是一项复杂的系统工程，遵循科学的排查思路，结合强大的排查工具，我们能够更高效、更准确地定位和解决性能问题，从而确保数据库系统始终处于最佳状态。
