必须运行oracle官方脚本hugepages_settings.sh计算并上浮5%，同时禁用thp和amm、配置vm.hugetlb_shm_group、kernel.shmmax/shmall及memlock，rac需全节点参数一致；否则即使数值正确也会静默降级。
oracle 19c 在大内存服务器上必须配 hugepages，否则 sga 超过 8gb 后，pagetables 消耗可能吃掉数 gb 内存，tlb 命中率暴跌，性能肉眼可见变慢——这不是“可选优化”，是上线前必做项。
怎么算 vm.nr_hugepages 才不报 ORA-27102
别用 sga_max_size / 2048 手算。Oracle SGA 实际占用大页数 = SGA 内存 + 保留区 + 对齐开销 + 内核向上取整，实测 6GB SGA 需要 3120 页（不是理论 3072），差这 48 页就会触发 ORA-27102: out of memory。
- 必须在数据库已
STARTUP状态下运行 Oracle 官方脚本：$ORACLE_HOME/rdbms/install/hugepages_settings.sh（注意是install/，不是admin/） - 脚本输出里找
Recommended setting: vm.nr_hugepages=XXXX这行，忽略其他说明文字 - 把该值再上浮 5%，例如脚本建议 3120，就设为 3276（向上取整到整数）
- 多实例共存？把每个实例的推荐值加总后再上浮 5%
改完 /etc/sysctl.conf 为什么 Oracle 还不用大页
只写 vm.nr_hugepages 是无效的。缺任意一项，Oracle 启动时会静默降级回普通页，grep Huge /proc/meminfo 显示 HugePages_Free 接近 HugePages_Total 就是典型假象——说明根本没绑定成功。
- 必须同时配置：
vm.hugetlb_shm_group = <oinstall_gid></oinstall_gid>（用id -g oinstall查） -
kernel.shmmax和kernel.shmall必须 ≥ SGA 实际大小（单位：字节 / 页），否则共享内存段创建失败 - 执行
sysctl -p后必须检查输出，有 warning 或 error 就得当场解决，不能跳过 - 改完需重启 Oracle 实例（不是 reload），大页分配发生在实例启动瞬间
为什么 ps 看 Oracle 进程 RSS 突然翻倍
这是正常现象，不是内存泄漏。启用 HugePages 后，Oracle 启动时就锁定全部 SGA 对应的大页，top 和 ps 的 RSS 列显示的是完整物理占用；而 free -h 的 Used 不会涨，大页内存单独统计在 /proc/meminfo 的 HugePages_* 字段里。
- 关键看
HugePages_Rsvd > 0且HugePages_Free显著下降（比如只剩个位数），才表示大页真正被 Oracle 绑定 - 如果
HugePages_Rsvd == 0，基本可断定失败，重点排查：use_large_pages=only是否生效、AMM 是否彻底禁用、memlock是否 unlimited、systemd 的LimitMEMLOCK是否放开 - RAC 环境所有节点的
vm.nr_hugepages、vm.hugetlb_shm_group、内核参数必须完全一致，否则集群状态异常
哪些前置条件不满足，大页一定失败
三个硬性前提缺一不可，漏掉任何一个，脚本算得再准也白搭。
- 透明大页（THP）必须永久禁用：
transparent_hugepage=never加进/etc/default/grub并grub2-mkconfig -o /boot/grub2/grub.cfg && reboot，临时 echo never 只撑不到重启 - AMM 必须关闭：
memory_target和memory_max_target两个参数必须从 SPFILE 中彻底删除（不能只设为 0），否则 ALTER SYSTEM 会报ORA-00843，需用 pfile 中转重建 spfile -
use_large_pages推荐设为AUTO_ONLY（19c Exadata 默认值），避免ONLY模式下因页数微小偏差直接拒启；但生产环境若追求确定性，仍可用ONLY，前提是计算和配置一步到位
最易被忽略的点：脚本必须在实例已启动后运行，且 oracle 用户要有读 /proc/<pid>/maps</pid> 权限；RAC 多节点场景下，哪怕只漏配一个节点的 vm.hugetlb_shm_group，那个节点的实例就永远用不上大页。
