Linux服务器启用HugePages可降低数据库内存延迟，但需确保内核支持、禁用透明大页、按SGA/shared_buffers计算并预分配足够连续物理内存，且数据库进程须显式启用；否则HugePages_Free为0或分配失败。
Linux服务器开启HugePages后，数据库（如Oracle、PostgreSQL）的内存访问延迟可显著下降，但直接配置vm.nr_hugepages往往不生效——根本原因是内核未预留足够连续物理内存，或应用未正确绑定大页。
确认系统是否支持并启用HugePages
先检查内核是否编译了HugePages支持，并查看当前状态：
$ grep -i huge /proc/meminfo HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB
Hugepagesize显示为2048 kB说明默认使用2MB大页（x86_64常见），若为1048576 kB则是1GB大页，需额外确认CPU是否支持（grep pdpe1gb /proc/cpuinfo）。
- 若
HugePages_Total为0且/proc/sys/vm/nr_hugepages不可写，可能是内核启动时禁用了大页（检查grubby --info=或/proc/cmdline中是否有transparent_hugepage=never或hugepagesz=0） - 某些云厂商虚拟机（如AWS EC2 t系列、部分OpenStack实例）因内存超分，默认禁用或无法分配大页，需换用内存优化型实例
- 容器环境（Docker/Podman）需显式添加
--privileged或--cap-add=SYS_RESOURCE才能修改nr_hugepages
计算并预分配HugePages数量
不能凭空指定数字——vm.nr_hugepages写入值必须≤当前可用连续物理内存所能支撑的大页数。对数据库而言，应覆盖其SGA/Shared Buffer等常驻内存区域：
- 以Oracle为例：取
sga_target或memory_target值（单位字节），除以Hugepagesize（如2097152），向上取整；再加10%余量防碎片 - PostgreSQL则参考
shared_buffers+work_mem * max_connections估算峰值共享内存需求 - 执行
echo 128 > /proc/sys/vm/nr_hugepages后，立刻检查/proc/meminfo中HugePages_Free是否同步变化；若仍为0，说明物理内存碎片化严重，需重启释放内存或调低目标值 - 永久生效需写入
/etc/sysctl.conf：vm.nr_hugepages = 128，但注意该参数在sysctl -p时仅尝试分配，失败不报错
数据库进程必须显式启用大页使用
分配完只是“准备好”，进程仍默认用普通页。关键在于启动前设置环境变量或参数：
- Oracle：在
$ORACLE_HOME/rdbms/admin/init.ora或spfile中设use_large_pages=only（推荐）或use_large_pages=true；若设为only而大页不足，实例将直接启动失败（报错ORA-27123），这是预期行为 - PostgreSQL：需在启动前设置
PGOPTIONS="-c shared_memory_type= mmap"并确保shared_buffers≥ 128MB（否则忽略大页），且内核vm.hugetlb_shm_group设为postgres用户gid - MySQL 8.0+：通过
large_pages系统变量启用，但仅支持InnoDB缓冲池，且要求innodb_buffer_pool_size是Hugepagesize整数倍 - 务必验证：启动后查
/proc/，看到类似/maps | grep huge 7f8b2c000000-7f8b34000000 rw-p 00000000 00:00 0 [heap] （huge）才表示生效
避免透明大页（THP）与显式HugePages冲突
两者机制互斥，共存会导致性能恶化甚至OOM。必须禁用THP：
- 临时禁用：
echo never > /sys/kernel/mm/transparent_hugepage/enabled和echo never > /sys/kernel/mm/transparent_hugepage/defrag - 永久禁用：在GRUB_CMDLINE_LINUX中追加
transparent_hugepage=never，然后grubby --update-kernel=ALL --args="transparent_hugepage=never"并重启 - 验证是否生效：
cat /sys/kernel/mm/transparent_hugepage/enabled输出应为[never]，而非[always] or [madvise] - 注意：某些发行版（如RHEL 8+）默认
madvise模式，虽不影响显式HugePages分配，但仍可能干扰内存统计，建议统一设为never
真正卡住的环节往往不是配置步骤，而是HugePages_Free始终不增加，或数据库日志里出现Failed to allocate huge pages却查不出原因——这时要盯住dmesg | tail -20，内核会明确告诉你“failed to allocate XXX pages due to memory fragmentation”或者“not enough contiguous memory”。物理内存连续性无法靠软件修复，只能靠重启或换实例。
