RHEL9.6+上vm.nr_hugepages超物理内存75%会导致sysctl -p失败或静默跳过，内核预分配失败后屏蔽该参数；需按物理内存×0.75计算安全上限，结合RAC多实例实际SGA总和+5%取整，并确保vm.hugetlb_shm_group、kernel.shmall、kernel.shmmax及memlock等配套参数合规，且HugePages_Rsvd>0才真正生效。
vm.nr_hugepages设太大直接导致sysctl -p失败
值设超物理内存75%在rhel9.6+上会触发内核拒绝加载，sysctl -p报错 "vm.nr_hugepages" is an unknown key 或静默跳过——这不是配置写错了，而是内核启动时预分配失败后直接屏蔽了该参数。尤其当 vm.swappiness=0 时，oom killer可能在crs启动前就把关键进程干掉，节点反复重启。
- 查当前物理内存：用
grep MemTotal /proc/meminfo得到字节数，换算成MB后 × 0.75 就是安全上限 - 别信脚本输出的“推荐值”就一定安全——
hugepages_settings.sh不校验物理内存余量，只算Oracle需求 - RAC多实例叠加后总值超过阈值？必须拆分：比如两个实例各需1600页，但总内存只撑住2500页，就得降SGA或改用
use_large_pages=auto
启动时静默失败但没报ORA-27102
不是所有失败都会打错误码。当 vm.nr_hugepages 过大导致内核无法预留，Oracle进程可能连pmon都拉不起来，CRS认为实例“超时未响应”，直接驱逐节点——日志里只有 CRS-2674: Start of 'ora.db1.inst' on 'node1' failed，alert.log 甚至为空。
- 第一排查点：
ps -ef | grep pmon看有没有对应实例的pmon进程；没有，说明根本没进Oracle启动流程 - 第二看内核日志：
dmesg -T | tail -20，找hugetlbpage或Out of memory相关条目，常有Cannot allocate memory for hugepages pool - 临时救急：把
/etc/sysctl.conf里vm.nr_hugepages改小（比如先设为0），sysctl -p后再试启实例，确认是否恢复
多个RAC实例共存时nr_hugepages叠加计算出错
脚本输出值是单实例视角，但RAC启动顺序不可控。如果节点上跑主库+ADG备库，或测试实例没停干净，hugepages_settings.sh 可能漏算某实例的映射段，最终 HugePages_Rsvd 始终为0，实例启动时 fallback 失败。
- 必须在所有目标实例都
STARTED（非MOUNT/OPEN）状态下运行脚本，ps -ef | grep pmon要看到全部实例进程 - 每个实例单独进其环境变量，执行一次脚本：
export ORACLE_SID=db1; $ORACLE_HOME/rdbms/install/hugepages_settings.sh - 把各输出里的
recommended nr_hugepages数值相加，再统一 +5% 向上取整——不是每个实例单独加5% - 验证关键指标：
cat /proc/meminfo | grep -i "hugepages_total\|hugepages_rsvd"，确保HugePages_Rsvd > 0且接近HugePages_Total
配套参数缺失导致大页实际不可用
只调 vm.nr_hugepages 是白忙。vm.hugetlb_shm_group、kernel.shmall、kernel.shmmax 缺一不可，任一不合规，Oracle启动时校验失败就退回到普通页，而 use_large_pages=only 下直接报 ORA-27102。
-
vm.hugetlb_shm_group必须设为oinstall组ID：id -g oinstall查值，写进/etc/sysctl.conf -
kernel.shmall单位是页数，要 ≥ SGA大小（字节）÷ 4KB；kernel.shmmax单位是字节，要 ≥ SGA大小——两者都得覆盖最大单个实例SGA -
memlock限制必须放开：oracle soft memlock unlimited和oracle hard memlock unlimited写进/etc/security/limits.conf，且重启session生效
HugePages_Rsvd 是否大于0——它才是Oracle真正拿到大页的铁证，而不是看 HugePages_Free 还剩多少。 
