oracle 11g rac中lms瓶颈本质是gc协调链路延迟与重试循环，而非cpu满载；_gc_policy_time=0禁用drm导致gc current block busy飙升，_lm_send/process_batching需设false防分片雪崩，parallel_force_local=true可收敛gc压力至单节点。
Oracle 11g RAC在突发高并发下LMS进程瓶颈不是“CPU被吃满”，而是GC协调链路卡在消息处理、响应延迟和重试循环上——根本原因在于默认参数与11g早期架构对突发流量缺乏缓冲和批处理弹性。
为什么_gc_policy_time设为0反而加剧LMS压力
11g中_gc_policy_time=0会禁用DRM（Dynamic Resource Management），看似减少计算开销，实则让GC策略完全退化为静态分配。当突发写入集中访问同一数据块（如sequence主键索引叶块），所有节点的LMS必须反复争抢该块的当前模式（current mode）权限，无法通过DRM动态迁移主控权。结果是：gc current block busy等待飙升，LMS线程在重试队列里不断轮询、超时、再发请求，CPU花在调度而非有效工作上。
- 查证方式：运行
SELECT inst_id, event, time_waited_micro/1000000 sec FROM gv$system_event WHERE event LIKE 'gc%' ORDER BY time_waited_micro DESC，若gc current block busy排前三且单次等待超500ms，说明已陷入重试风暴 - 安全值：11g建议设为
10（默认），不推荐0；若必须关DRM，需同步调大_lm_lms并确保私网带宽冗余≥30%
_lm_send_queue_batching和_lm_process_batching为何在11g比19c更关键
11g LMS的消息批处理逻辑较粗糙，_lm_send_queue_batching默认TRUE会把几十个锁请求打包成一个网络包发送。但突发高并发下，这个包可能远超MTU（尤其私网未调巨帧时），触发IP分片→丢包→TCP重传→LMS收不到ACK→超时重发→更多包堆积。这比19c的精细控制更容易雪崩。
- 必须设为
FALSE：禁用发送端打包，每个控制消息单独发，避免分片风险 - 配套设
_lm_process_batching=FALSE：接收端也不合并验证，防止单个坏包阻塞整批消息解析 - 注意：这两个参数在11g中修改后需重启实例，
scope=spfile不能热生效
为什么parallel_force_local=true能间接缓解LMS压力
11g默认允许跨节点并行（PX），一个并行查询可能在rac1发起、slave在rac2执行、结果回rac1聚合。这导致大量gc cr block request跨节点传输，LMS被迫高频处理小块一致性读请求。而parallel_force_local=true强制PX slave只在本地实例启动，把原本分散到多个LMS的GC压力，收敛到单节点LMS队列里——虽然单节点LMS负载升高，但消除了跨节点协调开销和网络抖动放大效应。
- 验证是否生效：查
SELECT * FROM v$px_session，若qcsid（query coordinator）和sid（slave）始终在同一inst_id，说明已生效 - 副作用：若某节点CPU或内存已饱和，强制本地PX可能引发本地资源争用，需同步监控
v$sysmetric中CPU Usage Per Sec和Memory Sorts Ratio
真正卡住LMS的从来不是它自己跑得多快，而是它等不到上游确认、收不到下游响应、又不敢丢弃重试请求——这些隐性延迟在11g的参数组合下极易被突发流量引爆，而日志里往往只留下ORA-600 [kjbrcrcvt:lms]或LMHB terminating the instance这类模糊信号。
