oracle rac私网延迟必须≤0.5ms，两两节点用私网ip执行ping -c 10测avg值；lms进程cpu持续＞50%、ges队列cum_queue_time＞100ms或＞500ms预警，需同步排查网络、lms配置及全局热点块。
查私网延迟是否超标（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 3 要抓传导路径）
gc cr request 很少孤立存在。典型恶化路径是：gc current request 延迟升高 → 远程块获取变慢 → 本地会话排队等块 → 触发 gc buffer busy acquire → 更多会话卡住 → LMS 负载反向飙升。
- 执行
oradebug -g all hanganalyze 3，重点识别类似'gc current request' 的依赖链 - 传导路径一旦成型，单纯调优 SQL 或加索引无效，必须回到网络/LMS/GES 三者协同定位
- 注意：hanganalyze 输出中若出现多个
gc类事件交叉引用，说明已进入雪崩前兆阶段
真正难处理的不是某个参数调错，而是三者中任意两个同时逼近阈值——比如私网 avg 刚到 0.48ms、LMS CPU 在 49% 波动、GES 队列 cum_queue_time 峰值卡在 95ms。这种临界状态不会报错，但响应时间开始毛刺化，容易被当成“偶发抖动”放过。
