lms进程cpu持续超50%即表明gc协调链路已出现瓶颈，需立即干预；须用ps命令逐个检查lms线程的%cpu和cls（应为ff而非ts），同步验证私网延迟（两两互测avg＞0.2ms即预警）、ges队列（cum_queue_time总和＞100ms预警）及调度策略（19c需手动kill -sigusr2重载rt模式）。
oracle rac中lms进程cpu持续超过50%，基本可以判定是gc协调链路已出现瓶颈，不是“要不要优化”的问题，而是“再不干预会引发重试风暴”的紧急状态。
确认LMS进程是否真在吃CPU
别只信top里带lms字样的进程——RAC里可能有lms0、lms1甚至lms9，它们是独立线程，必须逐个查。用这条命令抓实时负载：
ps -eo pid,ppid,comm,cls,pri,rtprio,%cpu --sort=-%cpu | grep lms
重点关注三列：comm是否为lms0类名称、%cpu是否持续＞50%、cls是否为ff（SCHED_FIFO）而非ts。若cls=ts，说明LMS根本没跑在RT模式，后续所有调优都白搭。
检查私网延迟是否超标
LMS高CPU往往不是它自己慢，而是等不到远端节点的响应。GC等待事件如gc current request首跳延迟直接受私网影响，必须用私网IP实测：
- 在每个节点上执行
ping -c 10 <rac_private_ip></rac_private_ip>，且必须两两互测（node1→node2、node1→node3、node2→node3） - 看
avg值，＞0.2ms就要警惕，＞0.5ms必须立刻处理 - 若某对节点间延迟异常，检查交换机buffer、jumbo frame（MTU必须全链路统一为9000，混用1500会触发分片重传）
验证GES队列是否积压
gv$ges_enqueue.cum_queue_time是GES层消息排队总耗时（毫秒），它不反映单次等待，而暴露系统级吞吐瓶颈：
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和私网；若所有实例都＞100ms，但私网延迟正常，则大概率是全局热点块（如序列索引页、高频更新配置表）引发连锁请求。
别盲目加LMS数量
_lm_lms是静态参数，改完必须重启实例，且加得越多越容易出问题：
- 19c默认按CPU核心数×0.5向上取整启动LMS，32核起16个已是上限
- 若
gc cr blocks received远低于gc current blocks served，说明LMS吞吐够用，瓶颈在别处 - 双节点RAC，
_lm_lms设为2~4足够，超6个几乎无收益，反而抬高上下文切换开销 - 真正该调的是
_gc_policy_time（默认10秒），缩短GC策略计算周期可减少批量块请求堆积
最常被忽略的一点：LMS调度策略未生效时，kill -SIGUSR2 <lms_pid></lms_pid>这步必须手动触发，19c不会自动重载——alert log里没出现at elevated (RT) priority就是铁证。
