LMS进程数不一致会破坏RAC的tickets流控机制：各节点ticket总量失衡，弱节点ticket耗尽后GC请求排队，触发off flow controlled messages飙升，导致TPS秒级归零；必须保证两节点_lm_lms值严格相等且启用实时调度。
lms进程数不匹配cpu核心数，会直接触发rac内部流控机制，tps断崖式下跌
为什么LMS数量不一致会导致流控（off flow controlled messages）飙升
Oracle RAC用tickets机制控制节点间消息发送节奏：每个LMS进程持有固定数量的ticket，发一条GC消息就扣一个，对端回传时返还。当某节点LMS进程数远少于另一节点（比如实例1有2个、实例2有8个），可用ticket总量不均衡，弱节点很快耗尽ticket，所有GC请求排队等待——GV$DLM_TRAFFIC_CONTROLLER里TCKT_AVAIL持续为0、TCKT_WAIT非零就是明证。此时% off flow controlled messages超过80%，大量事务卡在gc current multi block request或gc cr block busy上，TPS不是缓慢下降，而是秒级归零。
- 两节点RAC必须保证
_lm_lms值完全一致，不能靠默认计算（如32核机器自动起16个LMS）——某节点因OS限制只起了4个，就会成为瓶颈 -
_lm_lms是静态参数，改完必须重启实例，仅ALTER SYSTEM无效 - 检查命令：
SELECT inst_id, value FROM gv$parameter WHERE name = '_lm_lms'，对比两节点输出是否相等
盲目增加LMS数量反而压垮CPU调度器
19c默认按CPU核心数×0.5向上取整启动LMS，这不是安全上限。当私网带宽不足或UDP缓冲区未调大时，加LMS只是把GC请求更密集地塞进网络栈，引发内核级调度争抢：ps -eo pid,comm,cls,pri,rtprio,%cpu --sort=-%cpu | grep LMS会显示多个LMS进程%cpu总和超100%，但cls列仍是ts（非实时调度），说明它们在普通时间片里互相抢占，上下文切换暴涨，%sy（系统态CPU）反超%us（用户态）。
- 两节点RAC，
_lm_lms设为2~4足够；超过6个基本无收益，还可能触发ORA-4031 - 加LMS前先确认私网质量：用
ping -M do -s 8972测9000 MTU直达性，netstat -s | grep reasm看分片重组失败数是否归零 - 真正该调的是
_gc_policy_time（默认10秒），缩短GC策略计算周期可减少批量请求堆积，ALTER SYSTEM SET "_gc_policy_time"=5 SCOPE=SPFILE
LMS没跑在SCHED_FIFO实时调度，响应延迟放大GC压力
即使LMS数量正确，若未运行在实时调度模式，GC协调开销会翻倍。非RT模式下LMS线程被普通进程抢占，响应延迟升高，跨节点块请求来不及处理，触发重试与重复传输——表面看是LMS CPU高，实际是它卡在调度队列里，导致gc cr blocks received等待时间从毫秒级跳到秒级，TPS腰斩。
- 检查alert log是否有
at elevated (RT) priority字样；没有即失效 - 确认
_highest_priority_processes含LMS*：SHOW PARAMETER _highest_priority_processes - 确保
/etc/security/limits.conf含oracle soft rtprio 99和oracle hard rtprio 99 - 19c必须手动
kill -SIGUSR2 <lms_pid></lms_pid>重载调度策略，重启实例不自动生效
真正卡住TPS的从来不是LMS本身算得慢，而是它拿不到CPU时间片、等不到ticket、收不到UDP包——这三者环环相扣，调参时漏掉任意一环，吞吐量都回不来。
