优先选2mb大页，因postgresql等传统数据库默认仅支持2mb；1gb需cpu、内核及数据库版本（如oracle 19c+、mysql 8.0.30+、pg 15+）三重支持，并须显式配置与预留。
hugepages 用 1G 还是 2M？看内核版本和数据库进程模型
linux hugetlbpage 支持两种主流大小：2MB（x86_64 默认）和 1GB（需 CPU 和内核支持）。不是越大越好，得看数据库怎么申请内存。
PostgreSQL、Oracle 等传统数据库多用 mmap() + MAP_HUGETLB 绑定大页，它们通常只认 2MB 页面——哪怕你开了 1GB hugepages，cat /proc/meminfo | grep HugePages 显示有空闲，pg_ctl start 仍可能报 Cannot allocate memory。因为内核在 mm/hugetlb.c 里默认只把 2MB 页加入 hstate[0]，而多数 DB 的启动逻辑没显式指定 hstate index。
- 检查是否真支持 1GB：运行
grep pdpe1gb /proc/cpuinfo（有输出才支持），再确认内核编译了CONFIG_HUGETLB_PAGE_SIZE_1GB=y - Oracle 19c+、MySQL 8.0.30+（配合
large_pages=ON）可显式请求 1GB 页，但必须提前用echo 10 > /proc/sys/vm/nr_hugepages_1GB预留，不能靠nr_hugepages统一分配 - PostgreSQL 15 以前完全不识别 1GB 页；15+ 需设
huge_page_size = '1GB'且启动用户有CAP_IPC_LOCK，否则 fallback 到 2MB 或直接失败
绑定数据库内存时，/proc/sys/vm/hugetlb_shm_group 必须设对
很多 DB（如 PostgreSQL）用共享内存段（shmget()）承载 shared_buffers，而 hugepages 绑定共享内存依赖 hugetlb_shm_group。不设或设错组 ID，shmget() 就会静默退回到普通页，DB 日志里连 warning 都没有。
- 查数据库进程的 gid：
ps -o pid,gid,comm -C postgres，取 gid 值（比如 1001） - 写入：
echo 1001 > /proc/sys/vm/hugetlb_shm_group（重启后失效，建议加到/etc/sysctl.conf：vm.hugetlb_shm_group = 1001） - 错误现象：DB 启动成功，
cat /proc/meminfo | grep HugePages_Free不减，但cat /proc/<pid>/smaps | grep -i huge</pid>显示 0 kB AnonHugePages —— 说明根本没用上
numactl –membind 和 hugepages 冲突会导致 OOM
在 NUMA 架构服务器上，有人想“双重保险”：既用 numactl --membind=0 限定 CPU node，又开 hugepages。结果 DB 启动卡住，dmesg 出现 Out of memory: Kill process xxx (postgres) score xxx or sacrifice child。
原因在于：hugepages 是全局预分配资源，而 --membind 会强制所有内存分配（包括 hugepages backing memory）局限在指定 node。如果该 node 的空闲内存不足以容纳全部 hugepages（比如你预留了 100 个 2MB 页，但 node 0 只剩 150MB 可用），内核就无法完成 page fault，最终触发 OOM killer。
- 验证方法：
numastat -p <pid></pid>看Node 0 MemUsed是否远超HugePages_Total * 2MB - 安全做法：要么不用
--membind，改用numactl --cpunodebind=0 --membind=0启动 DB（确保 CPU 和内存同 node），要么关掉 hugepages 改用透明大页（transparent_hugepage=always） - 注意：PostgreSQL 的
shared_buffers分配发生在 postmaster 进程，所以必须对 postmaster 本身用 numactl，不是对 pgbench 等客户端
MySQL 的 innodb_buffer_pool_size 超过 hugepages 总量会静默降级
MySQL 8.0 开启 large_pages=ON 后，InnoDB 会尝试用 hugepages 分配 buffer pool。但如果 innodb_buffer_pool_size 设为 24G，而系统只预留了 10G hugepages（即 5120 个 2MB 页），它不会报错，而是自动切回普通页——此时 SHOW ENGINE INNODB STATUS 里 “Buffer pool size” 仍是 24G，但 cat /proc/meminfo | grep HugePages_Free 完全不变。
- 确认是否生效：查 MySQL 错误日志，成功绑定会打印
InnoDB: using huge pages；没这行就是降级了 - 计算公式：所需 hugepages 数 =
ceil(innodb_buffer_pool_size / 2MB)，再额外加 10% 缓冲（InnoDB 内部元数据也吃 hugepages） - 危险操作：动态调大
innodb_buffer_pool_size时，若 hugepages 不足，MySQL 会先释放旧 buffer pool（触发刷盘），再申请新内存——期间可能因普通页分配失败直接 crash
真正麻烦的是：这些机制都藏在内核和数据库启动路径深处，出问题时既不报错也不提示，只能靠 /proc 和日志交叉比对。别信“开了 hugepages 就一定用了”。