LMS进程未运行在RT模式（SCHED_FIFO）是Oracle 19c RAC中CPU飙升的隐性放大器：非RT模式下LMS响应延迟升高，引发GC跨节点请求排队、重试与重复传输，导致CPU超90%；需检查alert log无“at elevated (RT) priority”、ps确认cls为ts、_highest_priority_processes含LMS*、limits.conf配置rtprio权限，并kill -SIGUSR2触发调度策略重载。
LMS进程没跑在RT模式，CPU高时GC协调开销翻倍
oracle 19c rac中lms进程未运行在实时调度（sched_fifo）模式，是cpu飙升的隐性放大器。不是它本身吃cpu，而是当gc压力大时，非rt模式下lms响应延迟升高，导致跨节点块请求排队、重试、重复传输，最终把cpu推到90%以上。从alert log里看到lms1 started with pid=26, os id=29640_29663但没有at elevated (rt) priority字样，基本可判定调度策略异常。
检查方法：ps -eo pid,comm,cls,pri,rtprio,%cpu --sort=-%cpu | grep LMS。若cls列显示ts（即SCHED_OTHER），而非ff或rr，说明没生效。
- 确认
_highest_priority_processes参数已显式包含LMS：用show parameter _highest_priority_processes查，值应类似'LMS*,VKTM,LM*,LCK0,GCR*' - Linux内核需允许普通用户设置RT优先级：检查
/etc/security/limits.conf是否含oracle soft rtprio 99和oracle hard rtprio 99 - 重启数据库实例后，必须用
kill -SIGUSR2 <lms_pid></lms_pid>触发内核重新应用调度策略（仅19c需此步，早期版本自动生效）
盲目增加LMS数量反而加剧CPU争抢
加LMS进程数（_lm_lms）不是万能解药。19c默认按CPU核心数×0.5向上取整启动LMS，比如32核机器起16个LMS。但若私网带宽不足或GC等待事件（如gc cr block busy）已占AWR Top 5，硬加LMS只会让内核调度器更忙，线程上下文切换飙升，%sy（系统态CPU）占比反超%us。
判断是否真需要调增：SELECT inst_id, event, time_waited_micro/1000000 sec FROM gv$system_event WHERE event LIKE 'gc%' AND time_waited_micro > 0 ORDER BY time_waited_micro DESC。若单个事件等待秒数gc cr blocks received统计值远低于gc current blocks served，说明LMS吞吐够用，瓶颈在别处。
- 真正该调的是
_gc_policy_time（默认10秒）：缩短GC策略计算周期，减少批量块请求堆积，ALTER SYSTEM SET "_gc_policy_time"=5 SCOPE=SPFILE - 禁用无意义的LMS冗余：若RAC只有2节点，
_lm_lms设为2~4足够，超过6个几乎无收益 - 注意
_lm_lms是静态参数，改完必须重启实例，不能热加载
并行执行与LMS高CPU存在强耦合陷阱
当SQL启用并行（PX）且涉及跨节点表访问（如全局索引扫描、hash join broadcast），每个PX slave可能触发独立的GC请求。此时LMS不仅要处理常规缓存融合流量，还要应对短时爆发的、非均匀分布的块拉取请求，极易打满单个LMS线程。现象是top里某个LMSn CPU长期95%+，其他LMS却很闲。
验证方式：SELECT sql_id, degree, px_servers_requested, px_servers_allocated FROM gv$sql WHERE sql_id IN (SELECT sql_id FROM gv$session WHERE event = 'ON CPU') AND px_servers_requested > 1。若返回结果中degree值远高于实际物理CPU核数，大概率是并行度失控。
- 限制单SQL并行度上限：
ALTER SESSION SET parallel_max_servers = 8（按节点CPU数1/4设） - 对已知高GC开销的SQL，加hint禁止广播：
/*+ NO_PX_JOIN_FILTER(t1) */，强制走replicate而非broadcast - 避免在OLTP类SQL中用
PARALLELhint，RAC下它的GC成本常被低估3~5倍
最易被忽略的点：私网MTU和TCP栈配置
LMS进程的RT优先级和数量调优，全建立在私网通信低延迟基础上。若私网MTU仍为默认1500，而存储网络已调至9000（jumbo frame），LMS发送的GC包会被Linux内核分片，每个分片都触发一次中断+调度，直接废掉RT调度效果。同样，net.ipv4.tcp_slow_start_after_idle=0未关闭，会导致LMS连接空闲后重传窗口归零，突发GC流量时反复慢启动。
检查命令：ip link show dev <private_if> | grep mtu</private_if> 和 sysctl net.ipv4.tcp_slow_start_after_idle。两者必须与集群私网规划严格对齐。
- 私网MTU务必统一：所有节点
ifconfig <private_if> mtu 9000</private_if>，且交换机端口开启jumbo frame - 追加内核参数：
net.core.rmem_max=16777216、net.core.wmem_max=16777216，避免GC大包被丢弃 - 这些是OS层变更，不重启数据库也生效，但必须所有RAC节点同步执行，否则GC链路会降级到最低MTU节点的水平
