Oracle 11g RAC CPU日志告警与num_cpu_sockets配置咨询

关于修改num_cpu_sockets的作用 #

• 先明确：num_cpu_sockets是Oracle用于识别物理CPU插槽数的参数，当前数据库识别的1个插槽、3个核心与实际2插槽8核心的硬件配置完全不匹配，说明Oracle未正确感知硬件资源。
• 将num_cpu_sockets设为2，同时把num_cpu_cores调整为4（E5-2403单颗为4核心），能让Oracle准确认知硬件配置，调度器可更合理分配CPU资源，避免因识别错误导致的资源调度限制，理论上能更充分利用8核CPU。
• 注意：该参数为静态参数，修改后需重启实例生效，操作前务必做好数据库备份。

解决“CPU is high”告警及LMS进程未响应的其他方案 #

1. 彻底修正CPU识别参数 #

除了插槽数，必须同步修正num_cpu_cores为4（2颗×4核=8核），确保Oracle对硬件的认知完全匹配实际配置。先查询当前参数：

SELECT name, value FROM v$parameter WHERE name IN ('num_cpu_sockets', 'num_cpu_cores');

修改参数（需重启实例）：

ALTER SYSTEM SET num_cpu_sockets=2 SCOPE=SPFILE;
ALTER SYSTEM SET num_cpu_cores=4 SCOPE=SPFILE;

2. 排查LMS进程未响应的核心原因 #

LMS负责RAC全局缓存服务，其长时间未响应并非系统CPU使用率低导致，大概率与以下因素相关：

• 检查v$gc_wait_stats视图，查看是否存在频繁的gc cr request、gc current request等待——这类全局缓存争用会大幅增加LMS进程负载，即使系统整体CPU使用率低，LMHB监控的进程级CPU占用仍会触发告警。
• 测试节点间网络延迟，RAC节点间网络性能直接影响LMS进程效率，延迟过高会导致LMS处理缓存请求超时，引发未响应。可使用ping、mtr（Linux）等工具检测节点间网络的丢包率与延迟情况。

3. 调整LMHB告警阈值 #

Oracle 11g中LMHB的CPU告警阈值基于它识别到的CPU核心数计算，当前硬件识别错误会导致阈值不合理。可调整隐含参数_lmhb_cpu_usage_threshold，例如将阈值设为70（表示进程CPU使用率超过70%才触发告警）：

ALTER SYSTEM SET "_lmhb_cpu_usage_threshold"=70 SCOPE=SPFILE;

注：修改隐含参数前建议先在测试环境验证，或确认Oracle官方支持该调整。

4. 优化跨节点缓存访问 #

• 定位是否存在大量跨节点访问的SQL，例如频繁读取远程节点大表的语句，这类操作会加重LMS进程负担。建议通过调整分区策略将热点数据分散到本地节点，或使用物化视图同步数据。
• 查询v$session和v$process视图，定位占用LMS资源的会话，分析对应的SQL语句并进行优化。

5. 操作系统层面检查 #

• 确认操作系统是否正确识别CPU核心：Linux使用lscpu命令，Windows通过任务管理器查看CPU核心数。若系统层面未识别到8核CPU，需先修复系统硬件识别问题，再调整Oracle参数。
• 检查单个进程CPU占用情况：即使系统整体CPU使用率低，也可能存在个别进程占用单核心100%的情况，导致LMS进程调度受阻。可使用top（Linux）或任务管理器查看进程级CPU占用。

内容的提问来源于stack exchange，提问作者beibeitu