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高就盲目调参数，先验证根本原因。关键线索在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*' - /etc/security/limits.conf里得有
oracle soft rtprio 99和oracle hard rtprio 99，缺一不可 - 改完配置不重启数据库、不发
kill -SIGUSR2 <lms_pid></lms_pid>，调度策略不会生效——这是19c特有行为，早期版本自动重载
为什么加LMS数量反而让CPU更糟
盲目调大_lm_lms是高频误操作。19c默认按CPU核心数×0.5向上取整启动LMS（比如32核起16个），但这只是起点，不是上限。
真正瓶颈不在LMS数量，而在GC请求的响应质量。非RT模式下LMS延迟升高，导致gc cr block busy、gc buffer busy排队、重试、重复传输，最终把%sy（系统态CPU）顶到80%以上。
- 查真实GC压力：
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吞吐能力够，瓶颈在调度或网络 - 2节点RAC，
_lm_lms设为2~4足够；超过6个几乎无收益，还加剧内核调度开销
该调什么参数来降低GC协调开销
比加LMS更有效的动作，是缩短GC策略计算周期，减少批量块请求堆积。默认_gc_policy_time=10秒，意味着最多等10秒才触发一次全局资源协调。
把这个值压到5秒：ALTER SYSTEM SET "_gc_policy_time"=5 SCOPE=SPFILE，然后重启实例。实测在高并发短事务场景下，GC等待下降明显。
-
_gc_policy_time是静态参数，改完必须重启，不能热加载 - 配合检查私网带宽和延迟：
ping -s 8192 <remote_node_ip></remote_node_ip>看是否丢包或抖动超2ms - 禁用无意义的LMS冗余：确认
gv$process里LMS进程数与_lm_lms一致，避免残留旧进程抢资源
容易被忽略的底层依赖项
所有LMS优化的前提，是操作系统层面允许它跑在RT模式。很多人卡在最后一步：以为配了rtprio就完事，却忘了Linux内核默认限制普通用户使用实时调度。
除了limits.conf，还要检查：cat /proc/sys/kernel/sched_rt_runtime_us，若为-1或极小值（如950000），需同步调整sched_rt_runtime_us和sched_rt_period_us，否则即使权限开了，内核也会掐断RT进程的运行时间。
- 禁用透明大页（THP）是硬性要求：
echo never > /sys/kernel/mm/transparent_hugepage/enabled并写入GRUB - Oracle 19c对
numa敏感，建议在GRUB中加numa=off，避免LMS跨NUMA节点访问内存 - 不要依赖
top看LMS CPU，用pidstat -p <lms_pid> 1</lms_pid>抓连续1秒级数据，才能看出调度抖动
