Oracle RAC私网延迟需＜0.2ms，LMS进程CPU持续＞50%即危险，GES队列累计等待＞100ms预警；三者同步逼近阈值时须协同优化，否则单项调整无效。
查私网延迟：ping -c 10 rac_private_ip 看 avg > 0.2ms 就危险
oracle rac 对私网延迟极其敏感，gc current request 和 gc cr block 2-way 的首跳延迟直接受其影响。不要只信文档说的“
执行时注意三点：
- 必须用私网 IP（不是 VIP 或 public IP），且在所有节点两两之间都跑一遍，比如 node1 → node2、node1 → node3、node2 → node3
- 加
-c 10避免单次抖动误判，重点关注avg而非mdev - 若发现某对节点间 avg > 0.5ms，立刻检查交换机 buffer、jumbo frame 是否全链路一致（MTU 必须都是 9000，不能混用 1500）
看 LMS 进程 CPU：ps -eo pid,pcpu,comm | grep lms 找持续 > 50% 的 PID
LMS 是 GC 流量的最终承压点，CPU 不是“越高越好”，而是“不能持续 > 50%”。一旦超限，gc current block congested 就会指数级上升，因为 GES 消息队列开始积压。
排查时别只看 top 输出：
- 用
ps -eo pid,ppid,pcpu,pmem,comm --sort=-pcpu | grep lms查实时负载，确认是不是某个lms0或lms1单点吃满 - 结合
cat /proc/<pid>/stack</pid>看内核栈 —— 若卡在kslgetl或skgxp_receive，基本是锁争用或网络收包卡住 - 检查
GCS_SERVER_PROCESSES参数值是否匹配物理 CPU 核数（例如 16 核应设为 4~6，不是默认的 2）
验 GES 队列深度：查 gv$ges_enqueue.cum_queue_time 求和是否 > 100ms
cum_queue_time 是 GES 层消息排队总耗时，单位毫秒，它不反映单次等待，而暴露系统级吞吐瓶颈。>100ms 是预警线，>500ms 基本已触发重试风暴。
执行这个 SQL 并关注输出模式：
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 和私网 - 若所有实例都高，但私网延迟正常，则大概率是全局热点块（如序列索引页、高频更新配置表）引发的连锁请求
- 注意：该视图需在等待高峰期间采样，空闲期查不到真实压力
关联等待链：用 hanganalyze 3 抓住 gc current request → gc buffer busy acquire 的传导路径
GC 等待很少孤立存在。典型恶化路径是：gc current request 延迟升高 → 远程块获取变慢 → 本地会话排队等块 → 触发 gc buffer busy acquire → 更多会话卡住 → LMS 负载反向飙升。
抓链时关键动作：
- 在业务高峰期连上任意节点，执行：
oradebug setmypidoradebug unlimitoradebug -g all hanganalyze 3 - 重点搜
Chain.*gc current request.*gc buffer busy acquire，这种链说明不是纯网络问题，而是“请求已发、块未到、后续请求已在排队” - 若链中还夹着
enq: TX - row lock contention，说明底层是事务锁冲突放大了 GC 压力，得先压 SQL 并发度，再调 GC
真正难处理的从来不是单个指标超标，而是私网延迟 + LMS CPU + GES 队列三者同时逼近阈值 —— 此时任何单项优化都会被另一项拖回原点。务必同步采集三类数据再下结论。
