oracle rac私网延迟超标（avg>0.5ms）、lms cpu持续超50%、ges队列cum_queue_time>100ms三者任一出现即需干预，否则将引发gc cr request连锁阻塞与重试风暴。
查私网延迟是否超标（ping -c 10必须跑全链路）
Oracle 对私网延迟极其敏感，gc cr request 的首跳耗时直接受其影响。文档明确要求：平均延迟 > 0.5ms 就必须干预。
用私网 IP（不是 VIP 或 public IP），在所有节点两两之间执行 ping -c 10，例如 node1 → node2、node1 → node3、node2 → node3
- 只看
avg值，忽略mdev；单次抖动不重要，持续偏高才危险 - 若某对节点
avg > 0.5ms，立刻检查交换机 buffer 配置、jumbo frame 是否全链路一致——MTU 必须全是 9000，混用 1500 是高频死因 - 别信“网络没问题”的口头判断，RAC 私网不走 TCP 连接池，UDP 丢包或延迟会直接放大成等待
看 LMS 进程 CPU 是否持续过载（ps -eo pid,pcpu,comm 要盯住单个 PID）
LMS 是 GC 流量的最终承压点，CPU 不是“越高越好”，而是“不能持续 > 50%”。一旦超限，gc current block congested 会指数级上升。
- 用
ps -eo pid,ppid,pcpu,pmem,comm --sort=-pcpu | grep lms找出持续 > 50% 的lms0或lms1 - 结合
cat /proc/<pid>/stack</pid>看内核栈：卡在kslgetl是锁争用，卡在skgxp_receive是网络收包卡住 - 检查
GCS_SERVER_PROCESSES参数值是否匹配物理 CPU 核数（例如 16 核建议设为 4~6，不是默认的 2） - 别只看全局 CPU 使用率——LMS 可能被 OS 调度器饿死，需确认其调度优先级是否被压低
验 GES 队列是否积压（gv$ges_enqueue.cum_queue_time 要高峰采样）
cum_queue_time 是 GES 层消息排队总耗时（单位毫秒），它不反映单次等待，而暴露系统级吞吐瓶颈。> 100ms 是预警线，> 500ms 基本已触发重试风暴。
- 执行：
SELECT inst_id, SUM(cum_queue_time) queue_ms FROM gv$ges_enqueue GROUP BY inst_id ORDER BY queue_ms DESC; - 若某实例
queue_ms显著高于其他（比如 3 倍以上），优先查该节点的 LMS 和私网 - 若所有实例都高，但私网延迟正常，则大概率是全局热点块（如序列索引页、高频更新配置表）引发的连锁请求
- 该视图必须在等待高峰期间采样，空闲期查不到真实压力——AWR 报告里
Global Cache Load Profile中的CR blocks received只是总量，不体现排队深度
关联等待链是否形成传导（oradebug -g all hanganalyze）
gc cr request 高本身不一定是终点，常是上游问题的下游表现。比如 LMS 卡住 → GES 队列涨 → 其他会话等 gc cr request → 连锁阻塞。
- 执行
oradebug -g all hanganalyze 3获取当前全局等待图，重点看是否有环形依赖或长链 - 若发现
lms进程自身在等ges resource hashlatch 或gc cr grant busy，说明 GES 内部已出现资源争用 - 注意区分：如果
gc cr request和gc buffer busy acquire同时飙升，且集中在同一对象上，大概率是热点块而非网络问题 - AWR 中的
Avg global cache block receive time (ms)若 > 10ms，基本可判定私网已严重失能，此时再查 SQL 执行计划意义不大
