• 一、CPU 拉爆的定义与影响
  • 1.1 什么是"CPU 拉爆"
  • 1.2 CPU 拉爆的典型影响链
  • 1.3 V4 单进程架构下 CPU 问题的特殊性
• 二、CPU 拉爆的根因分类
  • 分类总览
  • A. SQL 层面问题（最高频，应急第一排查对象）
    • A1. 慢 SQL 导致 CPU 堆积
    • A2. 执行计划走飞（Plan Regression）
    • A3. SQL 并发打满（Concurrent Overload）
  • B. Compaction 等后台任务拉 CPU
    • B1. Major Compaction（每日合并 / major freeze）拉 CPU
    • B2. Minor Compaction / Dump 过于频繁
    • B3. 其他后台任务
  • C. 内核热点
    • C1. KVCache 原子引用计数热点
    • C2. Latch 竞争热点
    • C3. Plan Cache 问题
  • D. 资源不足 / 参数配置不当（Unit 配小了 / 线程池不对）
    • D1. 租户 CPU Unit 配小了
    • D2. 内存不足触发 Swap / 内存泄漏
    • D3. 关键系统参数配置不当
  • E. 业务突增 / 流量异常（连接风暴 / 重试风暴）
    • E1. 业务 QPS 突增
    • E2. 连接风暴
  • F. 系统层面问题（observer 部署环境检查）
    • F1. NUMA 配置不当
    • F2. THP（Transparent Huge Pages）干扰
    • F3. 内核参数不符合 OB 部署规范
• 三、CPU 拉爆的应急排查 SOP（标准作业流程）
  • 3.1 黄金 5 分钟排查流程
  • 3.2 详细排查步骤
    • Step 1：系统层面快速诊断（SSH 到节点执行）
    • Step 2：OB 内部诊断（通过 obclient 或 OCP 执行）
    • Step 3：线程级精准定位（perf + SQL Trace）
• 四、分级应急策略
  • 4.1 应急策略速查表
  • 4.2 P0 紧急止损操作手册（“应急五步法”）
  • 4.3 应急 SQL 工具箱（建议保存为快捷脚本）
• 五、预防与长期治理
  • 5.1 OCP 监控告警配置建议
  • 5.2 日常巡检清单（建议结合 OCP 巡检报告）
  • 5.3 容量规划建议（Unit 配置）
• 六、工具与资源速查
  • 6.1 诊断工具一览
  • 6.2 obdiag 常用命令（应急必备）
  • 应急三字诀
  • 应急常见踩坑点

阅读前置知识: 了解 OB 多租户架构、Zone/Unit/Tenant 资源模型、LS(Log Stream) 与 Tablet 概念、Compaction 机制（major/minor/mini）、SQL 引擎执行链路（SQE → 优化器 → 执行引擎 → 存储引擎）

一、CPU 拉爆的定义与影响

1.1 什么是"CPU 拉爆"

在 OB 应急语境中，CPU拉爆（也叫 CPU 打满、CPU 顶满）指observer 进程的 CPU 使用率持续超过 80%，甚至跑到 100%，通常伴随以下级联故障：

• SQL RT（Response Time）急剧飙升，从 ms 级恶化到秒级甚至分钟级
• 工作线程队列堆积（queue congestion），大量 session 排队等待
• OBProxy 侧连接打满，业务侧报 OB-4012: Timeout 或 -4016: Internal Error
• 严重时 observer 进程 hang 住（假死）或被系统 OOM Killer 杀掉，触发 Paxos 重新选主

OB 黑话科普：OB 内部我们一般说"CPU 拉爆"而不是"CPU 打爆"，"拉"字体现的是 CPU 被 SQL 或后台任务逐步拉上去的过程，更贴合实际故障现象。

1.2 CPU 拉爆的典型影响链

CPU 拉爆
  → 工作线程（worker thread）排队等不到 CPU 时间片
    → SQL RT 飙升，elapsed_time 中 queue_time 占比增大
      → OBProxy 侧连接池占满，新请求被 reject
        → 业务侧报 Timeout(-4012) / Connection Refused
          → 应用重试风暴 → 进一步加剧 CPU 压力（雪崩效应）
            → 业务全面中断，触发 GOC 应急

1.3 V4 单进程架构下 CPU 问题的特殊性

V4 相比 V3 架构做了重大重构，CPU 问题的排查思路也有本质区别：

V4 核心概念提醒：V4 中每个 observer 内部由多个 Log Stream (LS) 承载数据，每个 LS 下有多个 Tablet。SQL 执行链路经过 SQE（SQL Query Engine）解析优化后，由 PX/DFO 分发到各 tablet 所在节点执行。理解这条链路对定位 CPU 热点至关重要。

二、CPU 拉爆的根因分类

根据 GOC 处理过的大量 P0/P1/P2 应急案例复盘，CPU 拉爆的根因可分为 六大类：

分类总览

CPU 拉爆根因分类（按 GOC 实战频率排序）
├── A. SQL 层面（最常见，~50%）— 慢SQL / 计划走飞 / 并发打满
├── B. Compaction 等后台任务（~15%）— major freeze / minor compaction / dump
├── C. 内核热点 / 已知缺陷（~15%）— kvcache CAS / latch 竞争 / 内存分配热点
├── D. 资源不足 / 参数配置不当（~10%）— unit 配小了 / 线程池参数不对
├── E. 业务突增 / 流量异常（~5%）— 重试风暴 / 连接风暴 / 缓存穿透
└── F. 系统层面问题（~5%）— NUMA / THP / swap / 内核参数

A. SQL 层面问题（最高频，应急第一排查对象）

A1. 慢 SQL 导致 CPU 堆积

典型表现：

• 少量 SQL 的 elapsed_time 极高，在 gv$sql_audit 中一目了然
• logical_reads（逻辑读）或 get_count（KV 层 get 次数）极大
• 执行计划走飞，该走索引的走了全表扫描（PHY_TABLE_SCAN）

常见场景：

排查命令（应急三板斧）：

-- 【第一斧】查当前在跑的慢 SQL（is_exit=0 表示还在执行）
SELECT tenant_id, svr_ip, sid, trace_id,
       LEFT(query_sql, 200) AS sql_text,
       elapsed_time / 1000000 AS elapsed_sec,   -- 微秒转秒
       queue_time / 1000000 AS queue_sec,       -- 排队耗时
       logical_reads, physical_reads, get_count, -- 逻辑读/物理读/KV get
       plan_type, -- 0=本地计划 1=远程 2=分布式
       is_inner_sql
FROM oceanbase.gv$sql_audit
WHERE is_exit = 0
  AND elapsed_time > 1000000  -- 超过 1 秒
ORDER BY elapsed_time DESC
LIMIT 20;

-- 【第二斧】查执行计划（确认是否走飞）
EXPLAIN EXTENDED ;
-- 或用 EXPLAIN FORMAT=JSON 看详细代价
EXPLAIN FORMAT=JSON ;

-- 【第三斧】查 Top SQL 排行（按 CPU 总消耗排序，抓真正的 CPU 大户）
SELECT sql_id,
       LEFT(MIN(query_sql), 120) AS sql_text,
       COUNT(*) AS exec_count,
       ROUND(AVG(elapsed_time)/1000000, 2) AS avg_rt_sec,
       ROUND(SUM(cpu_time)/1000000, 2) AS total_cpu_sec,
       ROUND(AVG(logical_reads), 0) AS avg_logical_reads,
       ROUND(AVG(get_count), 0) AS avg_get_count
FROM oceanbase.gv$sql_audit
WHERE request_time > UNIX_TIMESTAMP(NOW() - INTERVAL 10 MINUTE) * 1000000
GROUP BY sql_id
ORDER BY total_cpu_sec DESC
LIMIT 20;

OB 老兵经验：plan_type 字段很关键 —— 0 是本地计划（Local Plan），2 是分布式计划（Dist Plan）。如果是分布式计划拉爆 CPU，说明涉及多机 shuffle，需要关注 PX worker 的并行度和数据倾斜。

A2. 执行计划走飞（Plan Regression）

典型表现：

• 之前跑得快的 SQL 突然变慢，RT 从 ms 级跳到秒级
• plan_hash_value 发生变化，走了不同的物理执行计划
• sql_audit 中 plan_type 可能从 0（本地计划）变成 2（分布式计划），代价陡增

常见原因：

• 统计信息过期：大批量 DML（INSERT/DELETE）后未触发自动统计信息收集，优化器基于过期的 NDV(列基数)/num_rows 选了错误计划
• major compaction 后计划失效：合并后 broadcast_version 推进，plan cache 中旧计划失效，重新生成可能选错
• 参数变更：optimizer_* 系列参数或 _nlj_batching_enabled 等隐藏参数被改过
• 全局索引失效：分区表的全局索引变为 UNUSABLE，导致回退到全表扫描

应急手段：

-- 1. 检查统计信息是否过期（关注 last_analyzed 和 stale_stats）
SELECT owner, table_name, last_analyzed, num_rows, stale_stats
FROM oceanbase.dba_tab_statistics
WHERE table_name = UPPER('');

-- 2. 手动收集统计信息（触发优化器重新感知数据分布）
ANALYZE TABLE . COMPUTE STATISTICS;
-- 或者增量收集（大表推荐，更快）
ANALYZE TABLE . COMPUTE STATISTICS FOR ALL COLUMNS SIZE AUTO;

-- 3. 绑定执行计划（SPM - SQL Plan Management）
-- 先从 sql_audit 找到之前跑得好的 plan_hash_value
SELECT sql_id, plan_hash_value, elapsed_time, plan_type
FROM oceanbase.gv$sql_audit
WHERE sql_id = ''
ORDER BY elapsed_time ASC LIMIT 5;

-- 用 plan baseline 固定好的计划
SELECT * FROM oceanbase.dba_sql_plan_baselines
WHERE sql_handle LIKE '%%';

-- 4. 紧急场景：直接清 plan cache 让所有计划重新生成
-- 注意：这是双刃剑，清完会短暂 CPU 尖刺（重新编译计划）
ALTER SYSTEM SET plan_cache_evict_interval = '5s';
-- 等恢复后记得改回来

A3. SQL 并发打满（Concurrent Overload）

典型表现：

• 同一类 SQL 大量并发执行，gv$sql_audit 中同一 sql_id 出现几十上百条 is_exit=0
• queue_time 显著增大（排队时间可能超过实际执行时间）
• CPU 跑到 100% 但单条 SQL 的 cpu_time 并不算很高（CPU 时间片被争抢）
• gv$ob_sql_workarea_memory_info 中 queue_size 持续走高

排查与应急：

-- 1. 查看当前各 SQL 的并发数（哪些 SQL 在排队）
SELECT sql_id, COUNT(*) AS concurrent_cnt,
       ROUND(AVG(queue_time)/1000000, 2) AS avg_queue_sec,
       ROUND(AVG(elapsed_time)/1000000, 2) AS avg_elapsed_sec
FROM oceanbase.gv$sql_audit
WHERE is_exit = 0
GROUP BY sql_id
ORDER BY concurrent_cnt DESC
LIMIT 10;

-- 2. 查看线程队列堆积情况
-- V4 中每个租户有独立的 request queue
SELECT tenant_id, svr_ip,
       in_queue_count, queue_size
FROM oceanbase.gv$tenant_runtime_info;

-- 3. 设置 query timeout 兜底（防止 SQL 长期霸占 CPU）
ALTER SYSTEM SET ob_query_timeout = 10000000 TENANT = ''; -- 10秒
-- 或 session 级别
SET ob_query_timeout = 10000000; -- 当前会话生效

-- 4. 紧急 Kill 会话（先确认不是关键 DML 事务！）
SHOW FULL PROCESSLIST;
KILL ;

-- 5. 通过 OCP 设置租户级并发限制（Resource Manager）
-- V4 支持通过 DBMS_RESOURCE_MANAGER 控制租户内资源组的并发
CALL DBMS_RESOURCE_MANAGER.CREATE_PLAN('emergency_plan');
CALL DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
  plan => 'emergency_plan',
  group_or_subplan => 'default',
  max_concurrency => 100  -- 限制最大并发
);

OB 老兵提醒：Kill 会话之前务必确认 trans_id，如果是大事务（affected_rows 很大），Kill 后回滚（rollback）也要消耗大量 CPU，可能短暂加剧问题。可以先让业务侧停发请求，等 CPU 降下来再处理。

B. Compaction 等后台任务拉 CPU

OB 背景知识：OB 存储引擎是 LSM-Tree 架构，数据先写 MemTable，达到阈值后 freeze → dump 成 mini SSTable，然后通过 mini compaction / minor compaction / major compaction 逐层合并。每一层 compaction 都会消耗 CPU + IO。

B1. Major Compaction（每日合并 / major freeze）拉 CPU

典型表现：

• 合并期间 CPU 明显升高（尤其是存储压缩解压的 CPU 开销）
• __all_virtual_zone_merge_info 中 major_compact_status = COMPACTING
• __all_virtual_tablet_compaction_progress 能看到大量 tablet 在合并
• OCP 上能看到合并任务在跑

排查与应对：

-- 1. 检查各 Zone 合并状态
SELECT zone, major_compact_status, broadcast_version,
       gmt_create AS last_start_time, last_finish_time
FROM oceanbase.__all_virtual_zone_merge_info;

-- 2. 检查 tablet 级合并进度（看还有多少没合完）
SELECT tenant_id, zone, status,
       COUNT(*) AS tablet_cnt
FROM oceanbase.__all_virtual_tablet_compaction_progress
GROUP BY tenant_id, zone, status;

-- 3. 检查是否有合并报错（卡住的合并可能拉 CPU）
SELECT * FROM oceanbase.__all_virtual_zone_merge_info
WHERE major_compact_status = 'ERROR';

-- 4. 【紧急】暂停合并（业务高峰期拉 CPU 时的第一止损手段）
ALTER SYSTEM SUSPEND MERGE;

-- 5. 【低峰期】恢复合并
ALTER SYSTEM RESUME MERGE;

-- 6. 调整合并时间窗口（避免高峰期触发 major freeze）
ALTER SYSTEM SET merge_schedule_policy = 'schedule_time=02:00-06:00';
-- 或者通过 OCP 设置“合并时间窗口”

OB 老兵经验：major compaction 的 CPU 消耗主要来自 SSTable 数据的压缩/解压和重写。如果开了 zstd 压缩，合并时 CPU 开销会更大。可以临时把 compaction_memory_bytes_limit 调小来降低合并并发。

B2. Minor Compaction / Dump 过于频繁

典型表现：

• 写入压力大的租户，MemTable 频繁 freeze + dump
• __all_virtual_tablet_compaction_progress 中大量 mini/minor compaction 任务堆积
• 写放大严重，CPU 和 IO 同时拉高

应对：

-- 调整写入限速阈值（避免写入过快导致 MemTable 爆仓）
ALTER SYSTEM SET writing_limit_trigger_percentage = 80;

-- 调整 minor compaction 触发阈值
ALTER SYSTEM SET minor_compact_trigger = 4;  -- mini sstable 数达到 4 时触发 minor

-- 检查 MemTable 内存使用（是否快爆了）
SELECT tenant_id, svr_ip, freeze_trigger,
       memstore_used, memstore_limit
FROM oceanbase.gv$tenant_runtime_info;

B3. 其他后台任务

C. 内核热点

C1. KVCache 原子引用计数热点

问题描述：

• OBServer 存储引擎层的 KVCache（行缓存）的引用计数 (ref_cnt) 和序列号 (seq_num) 共用一个 int64
• 高并发下 CAS（Compare-And-Swap）操作频繁失败，CPU 空转（spin）
• 火焰图特征：dec_ref_cnt_and_inc_seq_num 函数占比显著（超过 5%）

触发条件：

• 高并发点查 + 索引回表场景（非覆盖索引 → 通过 SSTable 回表 → 经过 KVCache → 触发热点）
• row cache 越小（内存规格越低），同一个 2M block 上不同 KV 越多，命中概率越高

影响版本：V4.2.x BP 系列及更早版本，V4.3.5 已修复（重构了引用计数实现）

排查方法：

# 1. 抓取火焰图（perf，这是定位内核热点的核武器）
perf record -g -p $(pgrep observer) -- sleep 30
perf report --stdio > perf_report.txt
# 2. 检查热点函数（看占比）
perf report --sort=symbol | head -30
# 3. 关注以下调用栈（看到这个栈基本就是 KVCache 热点）
# ObSSTableMultiPrefetcher::~ObSSTableMultiPrefetcher
#   → ObKVCacheHandle::~ObKVCacheHandle
#     → ObAtomicReference::dec_ref_cnt_and_inc_seq_num  ← 热点函数
# 4. 也可以用 obdiag 一键采集
obdiag gather all --since "30m"
# 采集结果发给研发分析

应急手段（按优先级）：

C2. Latch 竞争热点

常见场景：

• 高并发下内部 latch（轻量锁）竞争，CPU 在 spin-wait 上空转
• plan cache latch（plan cache 淘汰时加锁竞争）
• alloc/dealloc 热点（ob_malloc / ob_free 或 jemalloc 相关）
• row lock（行锁）争用，事务并发过高

排查：

# perf 抓取锁热点
perf record -e cycles -g -p $(pgrep observer) -- sleep 10
perf report --sort=symbol,dso
# 关注以下函数
# - ob_latch_rdlock / ob_latch_wrlock  ← OB 内部 latch
# - ob_malloc / ob_free / je_malloc    ← 内存分配热点
# - __pthread_mutex_lock               ← 系统级锁竞争

-- 查看 latch 统计（哪个 latch 竞争最严重）
SELECT latch_id, name, gets, misses,
       ROUND(misses/NULLIF(gets,0)*100, 4) AS miss_pct
FROM oceanbase.gv$latch
WHERE misses > 0
ORDER BY misses DESC
LIMIT 20;

C3. Plan Cache 问题

问题：plan cache 过大导致淘汰时 CPU 升高；或 plan cache 命中率低，大量 SQL 需要重新编译计划

-- 检查 plan cache 状态（关注命中率和内存使用）
SELECT tenant_id, svr_ip,
       plan_cache_size, mem_used, plan_num,
       ROUND(hit_count/NULLIF(access_count,0)*100, 2) AS hit_pct
FROM oceanbase.gv$plan_cache_status;

-- plan cache 命中率低于 90% 需要关注
-- 必要时清理 plan cache（谨慎操作，会短暂 CPU 尖峰）
ALTER SYSTEM SET plan_cache_evict_interval = '30s';
-- 恢复后改回默认

D. 资源不足 / 参数配置不当（Unit 配小了 / 线程池不对）

D1. 租户 CPU Unit 配小了

V4 中租户资源通过 Resource Pool → Resource Unit 模型管理。Unit 的 min_cpu / max_cpu 决定了租户能拿到的 CPU 上下限。

-- 1. 检查租户资源单元配置
SELECT t.tenant_name, t.tenant_id,
       u.unit_config_id, u.unit_name,
       u.min_cpu, u.max_cpu,
       u.memory_size/1024/1024/1024 AS memory_gb
FROM oceanbase.dba_ob_tenants t
JOIN oceanbase.dba_ob_resource_pools p ON t.tenant_id = p.tenant_id
JOIN oceanbase.dba_ob_unit_configs u ON p.unit_config_id = u.unit_config_id;

-- 2. 检查各节点 CPU 实际分配情况
SELECT svr_ip, tenant_id,
       SUM(cpu_assigned) AS cpu_assigned,
       SUM(cpu_used_max) AS cpu_used_max
FROM oceanbase.gv$ob_processlist
GROUP BY svr_ip, tenant_id;

-- 3. 【紧急扩容】调大 Unit 的 CPU（OCP 操作更方便）
ALTER RESOURCE UNIT  MIN_CPU = 16, MAX_CPU = 32;

-- 4. 如果集群有富余节点，也可以通过加 Unit 横向扩容
-- 通过 OCP “增加 Unit” 操作

OB 老兵提醒：V4 中 min_cpu 是硬保障（预留），max_cpu 是上限。如果 min_cpu 设小了，即使机器有空闲 CPU，租户也拿不到。OLTP 业务建议 min_cpu = max_cpu，不超卖。

D2. 内存不足触发 Swap / 内存泄漏

表现：CPU 高 + iowait 高 + vmstat 的 si/so 不为 0（在用 swap）

-- 检查各租户内存使用
SELECT svr_ip, tenant_id,
       ROUND(mem_used/1024/1024/1024, 2) AS mem_used_gb,
       ROUND(mem_limit/1024/1024/1024, 2) AS mem_limit_gb,
       ROUND(mem_used/mem_limit*100, 2) AS mem_pct
FROM oceanbase.gv$tenant_runtime_info;

-- 检查模块级内存使用（看哪个模块吃内存最多）
SELECT tenant_id, svr_ip, module,
       ROUND(hold/1024/1024, 0) AS hold_mb,
       ROUND(used/1024/1024, 0) AS used_mb
FROM oceanbase.gv$ob_memory
WHERE hold > 100*1024*1024  -- 超过 100MB 的模块
ORDER BY hold DESC;

# 系统层面检查 swap
free -h
vmstat 1 5
# si/so 不为 0 → 说明在用 swap → observer 性能会严重下降

D3. 关键系统参数配置不当

E. 业务突增 / 流量异常（连接风暴 / 重试风暴）

E1. 业务 QPS 突增

典型场景：

• 促销活动、定时任务集中触发，OBProxy 侧 QPS 陡增
• 上游重试风暴（网络抖动后应用侧疯狂重试）
• Redis/缓存失效导致的数据库穿透（cache miss storm）

应急手段：

-- 1. 确认连接数 / QPS 变化
SELECT svr_ip, tenant_id, COUNT(*) AS session_count
FROM oceanbase.gv$ob_processlist
GROUP BY svr_ip, tenant_id;

-- 2. 设置连接数上限（防止雪崩）
ALTER SYSTEM SET max_connections = 500;

-- 3. 租户级限流（V4 Resource Manager 支持）
CALL DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
  plan => 'peak_protection',
  group_or_subplan => 'app_group',
  max_concurrency => 200,  -- 限制最大并发
  max_iops => 10000,
  mgmt_p1 => 50
);

-- 4. 业务侧配合：让应用侧临时停发请求 / 加指数退避

E2. 连接风暴

表现：短时间内大量新连接涌入，OBProxy 的连接打满，observer CPU 瞬间拉爆

OB 特有现象：连接建立时需要做认证、分配 session 内存，大量并发连接会触发 observer 内部内存分配热点。

-- 快速查看当前连接状态
SHOW FULL PROCESSLIST;

-- 查看各租户连接分布
SELECT tenant, COUNT(*) AS cnt, state
FROM information_schema.processlist
GROUP BY tenant, state
ORDER BY cnt DESC;

-- 批量 Kill 空闲或异常连接（先确认不是关键业务！）
SELECT CONCAT('KILL ', id, ';')
FROM information_schema.processlist
WHERE command = 'Sleep' AND time > 60;

F. 系统层面问题（observer 部署环境检查）

F1. NUMA 配置不当

OB 规范要求：observer 必须用 numactl --interleave=all 启动，否则跨 NUMA 节点内存访问会导致 CPU 开销显著增加。

# 检查 NUMA 状态
numactl --hardware
numactl --show
# 检查 observer 进程的 NUMA 策略
cat /proc/$(pgrep observer)/numa_maps | head -5
# 正确启动方式（必须在 observer 启动脚本中配置）
numactl --interleave=all /home/admin/oceanbase/bin/observer

F2. THP（Transparent Huge Pages）干扰

OB 规范要求：THP 必须关闭。THP 会导致内存分配时出现大页延迟，影响 observer 的 RT。

# 检查 THP 状态（应显示 [never]）
cat /sys/kernel/mm/transparent_hugepage/enabled
# 关闭 THP
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

F3. 内核参数不符合 OB 部署规范

# OB 标准内核参数检查（与 obd 部署工具检查项对齐）
sysctl vm.swappiness          # 必须 = 0，禁止 swap
sysctl vm.overcommit_memory   # 建议 = 0
sysctl net.core.somaxconn     # 建议 >= 65535
sysctl net.ipv4.tcp_tw_reuse  # 建议 = 1
sysctl fs.file-max            # 建议 >= 655350
# 检查 observer 文件描述符限制
ulimit -n  # 建议 >= 655350

三、CPU 拉爆的应急排查 SOP（标准作业流程）

3.1 黄金 5 分钟排查流程

[0-1min]  确认问题 → 登录 OCP，看 CPU 监控趋势；确认是单节点还是全集群
    ↓
[1-2min]  定位线程 → SSH 到节点，top -H -p  看哪些线程 CPU 高
    ↓
[2-3min]  关联 SQL → 查 gv$sql_audit（is_exit=0），关联 trace_id 找到高 CPU SQL
    ↓
[3-4min]  判断类别 → 区分 SQL 问题 / Compaction 拉 CPU / 内核热点 / 资源不足
    ↓
[4-5min]  执行止损 → Kill SQL / SUSPEND MERGE / 扩 Unit / 限流

3.2 详细排查步骤

Step 1：系统层面快速诊断（SSH 到节点执行）

# 1.1 查看整体 CPU 使用（关注 us/sy/wa/id）
top -bn1 | head -20
# 1.2 查看 observer 线程级 CPU（V4 单进程，必须看线程）
top -H -p $(pgrep observer) -bn1 | head -40
# 1.3 查看 CPU 各核使用情况（是否有单核打满）
mpstat -P ALL 1 3
# 1.4 查看是否有 iowait（可能是 IO 问题伪装的 CPU 问题）
iostat -x 1 3
# 关注 await、util 指标，如果 await > 10ms 或 util > 90% → IO 瓶颈
# 1.5 查看 swap（observer 绝对不能用 swap）
free -h
# 1.6 查看系统日志是否有 OOM / observer crash
dmesg | grep -i "oom\|killed\|out of memory" | tail -20
# 1.7 检查 observer 日志是否有异常（WARN/ERROR）
tail -1000 /home/admin/oceanbase/log/observer.log | grep -E 'WARN|ERROR' | tail -20

Step 2：OB 内部诊断（通过 obclient 或 OCP 执行）

-- 2.1 查看当前活跃 SQL（is_exit=0 表示还在跑）
SELECT tenant_id, svr_ip, sid, trace_id,
       LEFT(query_sql, 150) AS sql_text,
       elapsed_time / 1000000 AS elapsed_sec,
       queue_time / 1000000 AS queue_sec,
       logical_reads, physical_reads, get_count,
       plan_type  -- 0=Local 1=Remote 2=Distributed
FROM oceanbase.gv$sql_audit
WHERE is_exit = 0
ORDER BY elapsed_time DESC
LIMIT 20;

-- 2.2 查看租户级别的 CPU 消耗（哪个租户在拉 CPU）
SELECT tenant_id, svr_ip,
       ROUND(SUM(cpu_time)/1000000, 2) AS total_cpu_sec,
       COUNT(*) AS active_sessions
FROM oceanbase.gv$sql_audit
WHERE request_time > UNIX_TIMESTAMP(NOW() - INTERVAL 5 MINUTE) * 1000000
GROUP BY tenant_id, svr_ip
ORDER BY total_cpu_sec DESC;

-- 2.3 查看等待事件（V4 性能诊断利器）
SELECT event, wait_class, COUNT(*) AS wait_cnt,
       ROUND(AVG(wait_time_micro), 0) AS avg_wait_us,
       ROUND(SUM(timeouts), 0) AS total_timeouts
FROM oceanbase.gv$session_wait
GROUP BY event, wait_class
ORDER BY wait_cnt DESC
LIMIT 20;
-- 重点关注：
-- "row lock wait" → 行锁竞争
-- "SQL QUEUEING" → 工作线程不足，SQL 在排队
-- "PX QUEUEING" → PX worker 不够
-- "db file data read" → 物理 IO 多

-- 2.4 查看 Compaction 状态（是否在跑 major/minor）
SELECT zone, major_compact_status, broadcast_version
FROM oceanbase.__all_virtual_zone_merge_info;
SELECT tenant_id, zone, status, COUNT(*) AS tablet_cnt
FROM oceanbase.__all_virtual_tablet_compaction_progress
GROUP BY tenant_id, zone, status;

-- 2.5 查看线程队列堆积
SELECT svr_ip, tenant_id,
       queue_size, in_queue_count
FROM oceanbase.gv$ob_sql_workarea_memory_info;

-- 2.6 查看 MemTable 内存状态（是否快爆了导致频繁 freeze）
SELECT tenant_id, svr_ip,
       ROUND(memstore_used/1024/1024/1024, 2) AS memstore_used_gb,
       ROUND(memstore_limit/1024/1024/1024, 2) AS memstore_limit_gb,
       freeze_trigger, active_freeze_trigger
FROM oceanbase.gv$tenant_runtime_info;

Step 3：线程级精准定位（perf + SQL Trace）

# 3.1 获取高 CPU 线程的 LWP（轻量级进程号）
top -H -p $(pgrep observer) -bn1 | awk '$9 > 10 {print $1, $9}' | head -20
# 3.2 将 LWP 转为十六进制（用于关联 observer 日志中的线程号）
printf '%x\n' 
# 3.3 通过 pstack 抓取线程栈（生产慎用，可能导致 observer 短暂 hang）
pstack $(pgrep observer) > pstack_$(date +%Y%m%d%H%M).txt
# 3.4 通过 perf 抓取火焰图（推荐！内核热点定位的终极武器）
perf record -g -F 99 -p $(pgrep observer) -- sleep 30
perf script | stackcollapse-perf.pl | flamegraph.pl > flame.svg
# 3.5 通过 obdiag 一键采集（最推荐，自动化程度高）
obdiag gather all --since "30m"
# 会自动采集 perf、日志、sql_audit、系统信息等，打包发给研发

-- 3.6 V4 SQL Trace 诊断（推荐）
-- 开启 SQL Trace 捕获详细执行信息
ALTER SYSTEM SET trace_log_slow_query_watermark = '1s';
-- 慢查询日志在 /home/admin/oceanbase/log/observer.log.slow_query

-- 3.7 关联 trace_id 查看完整执行链路
SELECT * FROM oceanbase.gv$sql_audit
WHERE trace_id = '';

四、分级应急策略

4.1 应急策略速查表

4.2 P0 紧急止损操作手册（“应急五步法”）

# ===== 第一步：快速 Kill 慢 SQL =====
# 通过 obclient 经 OBProxy 连接（也可以直接连 observer 的 2881 端口）
obclient -h -P -u@# -p -D
# 找到问题 SQL 的 session
SELECT id, user, host, db, command, time, state, LEFT(info, 100) AS sql_text
FROM information_schema.processlist
WHERE time > 5 AND command != 'Sleep'
ORDER BY time DESC;
# Kill 对应 session（注意：先确认不是关键 DML 事务！）
KILL ;
# ===== 第二步：紧急扩 Unit CPU =====
# 通过 OCP 操作更方便：租户管理 → 资源单元 → 修改
# 或通过 SQL
ALTER RESOURCE UNIT unit_xxx MIN_CPU = 32, MAX_CPU = 64;
# ===== 第三步：暂停 Compaction =====
ALTER SYSTEM SUSPEND MERGE;  -- 暂停 major compaction
# ===== 第四步：设置 SQL 超时兆底 =====
ALTER SYSTEM SET ob_query_timeout = 30000000 TENANT = '';  -- 30秒
ALTER SYSTEM SET ob_trx_timeout = 30000000 TENANT = '';   -- 事务超时 30秒
# ===== 第五步：如仍无法恢复，考虑重启 observer =====
# 注意：这是最后手段！
# 重启会触发 Paxos 选主，其他节点接管 leader，业务会短暂中断
# 必须通过 OCP 操作，不能手动 kill -9
# 重启前确认其他节点健康，避免多个节点同时不可用

4.3 应急 SQL 工具箱（建议保存为快捷脚本）

-- 批量生成 Kill 语句（超过 60 秒的非 Sleep 会话）
SELECT CONCAT('KILL ', id, ';')
FROM information_schema.processlist
WHERE time > 60 AND command != 'Sleep';

-- 最近 10 分钟 Top SQL（按 CPU 总消耗排序）
SELECT sql_id,
       LEFT(MIN(query_sql), 120) AS sql_text,
       COUNT(*) AS exec_cnt,
       ROUND(AVG(elapsed_time)/1000000, 2) AS avg_rt_sec,
       ROUND(AVG(queue_time)/1000000, 2) AS avg_queue_sec,
       ROUND(AVG(logical_reads), 0) AS avg_lreads,
       ROUND(AVG(get_count), 0) AS avg_gets,
       MAX(plan_type) AS plan_type
FROM oceanbase.gv$sql_audit
WHERE request_time > UNIX_TIMESTAMP(NOW() - INTERVAL 10 MINUTE) * 1000000
GROUP BY sql_id
ORDER BY SUM(cpu_time) DESC
LIMIT 20;

-- 查看当前 Compaction 状态（是否需要 SUSPEND MERGE）
SELECT zone, major_compact_status, broadcast_version,
       gmt_create AS start_time, last_finish_time
FROM oceanbase.__all_virtual_zone_merge_info;

-- 快速查看租户资源使用全景
SELECT t.tenant_name, t.tenant_id,
       u.min_cpu, u.max_cpu,
       r.mem_used_percent,
       r.cpu_used_percent
FROM oceanbase.dba_ob_tenants t
JOIN oceanbase.dba_ob_resource_pools p ON t.tenant_id = p.tenant_id
JOIN oceanbase.dba_ob_unit_configs u ON p.unit_config_id = u.unit_config_id;

-- 检查 Paxos 状态（是否有节点不可用 / leader 分布不均）
SELECT tenant_id, ls_id, svr_ip, role, member_list
FROM oceanbase.gv$ob_log_stat
WHERE role = 'LEADER'
ORDER BY tenant_id, ls_id;

五、预防与长期治理

5.1 OCP 监控告警配置建议

5.2 日常巡检清单（建议结合 OCP 巡检报告）

• 检查 CPU 使用率趋势（近 7 天，关注是否有周期性尖峰）
• 检查 Top SQL 排行（是否有新增慢 SQL / 计划走飞）
• 检查统计信息 stale_stats（是否有表统计信息过期）
• 检查 major compaction 是否在预期窗口完成（major_compact_status）
• 检查 plan cache 命中率（> 95% 为正常，低于 90% 需关注）
• 检查等待事件（是否有异常的 row lock wait / SQL QUEUEING）
• 检查资源单元配置（Unit 的 min_cpu / max_cpu / memory_size 是否合理）
• 检查 MemTable 使用率（是否接近 freeze_trigger）
• 检查日志归档状态（log_archive_dest 是否正常）
• 检查节点 Paxos 状态（是否有节点长期 follower，leader 分布是否均衡）

5.3 容量规划建议（Unit 配置）

OB Unit CPU 配置公式：
  目标 Unit min_cpu = 预估 QPS × 平均 CPU 耗时(ms) / 1000 / 目标CPU利用率(0.6)

示例：
  QPS = 10000, 平均 CPU 耗时 = 2ms
  所需 CPU = 10000 × 2 / 1000 / 0.6 ≈ 33 核

安全余量建议：实际分配 = 计算值 × 1.5（预留高峰 + Compaction 等后台任务）

注意事项：
- OLTP 业务建议 min_cpu = max_cpu，不超卖
- HTAP 场景建议 OLTP 和 OLAP 用不同租户隔离
- 考虑 major compaction 的 CPU 开销（压缩算法选型影响很大）

六、工具与资源速查

6.1 诊断工具一览

6.2 obdiag 常用命令（应急必备）

# 一键性能诊断（分析 observer 日志中的 WARN/ERROR）
obdiag analyze log --since "30m"
# 分析指定 SQL 的执行详情
obdiag analyze sql --sql_id ""
# 巡检报告（生成全面的健康检查报告）
obdiag check
# 采集诊断信息（打包发给研发分析，应急时必做）
obdiag gather all --since "1h"
# 会自动采集：perf、observer日志、sql_audit、系统信息、火焰图等

应急三字诀

1. 快：5 分钟内定位问题类别，先止损再根因。CPU 拉爆时每一秒都在损失业务。
2. 准：gv$sql_audit + top -H 是应急双绝，精准定位高 CPU 线程和问题 SQL。
3. 稳：止损动作要评估副作用 —— Kill 会话前确认不是关键 DML 事务；SUSPEND MERGE 后记得低峰期 RESUME；扩 Unit 要考虑集群资源余量。

应急常见踩坑点

本文档基于 OB GOC 团队实战经验整理，适用于 OceanBase V4 系列版本。如有新的典型案例或解决方案，欢迎及时补充至知识库。