确认进程是否真用2mb大页需查/proc/[pid]/smaps中mmupagesize=2048且mmupageoffset=0；仅看hugepages_free减少无效，因可能未实际绑定；oracle需use_large_pages=only并ulimit -l unlimited，postgresql 9.6+需huge_pages=on且shared_buffers整除大页大小。
怎么确认进程是否真的用了2MB大页
光看 /proc/meminfo 里 HugePages_Free 变少了没用，很多场景下它减了，但目标进程根本没用上。真正要看的是进程自己的内存映射细节。
最直接的方式是查 /proc/<pid>/smaps</pid>（把 <pid></pid> 换成实际进程号）：
- 搜索
MMUPageSize字段：值为2048表示该内存段走的是 2MB 大页；4就是普通 4KB 页 - 同时检查
MMUPageOffset是否为0，非零说明对齐失败，哪怕标了MAP_HUGETLB也可能回退到小页 - 注意：有些老版本内核或工具（如
ps -eo hugemem）不支持该字段，优先以smaps为准
为什么 echo 1024 > /proc/sys/vm/nr_hugepages 成功了，但进程还是分配失败
核心原因是：大页分配依赖连续物理内存，而 /proc/sys/vm/nr_hugepages 只是“申请额度”，不是“立刻划拨”。系统在写入时会尝试从 buddy 系统里找连续的 2MB 块，失败就静默忽略。
- 典型现象：
cat /proc/meminfo | grep HugePages_Free不变，或只增加几页 - 运行中内存碎片高（尤其长时间运行后），即使
free -h显示空闲内存充足，也常失败 - 解决路径只有两个：重启前静态配置（改
grub），或提前预留——比如开机后立刻执行echo 2048 | sudo tee /proc/sys/vm/nr_hugepages，别等服务启动完再配
Oracle/PostgreSQL 这类服务启用 HugePages 的关键卡点
分配大页只是第一步，服务进程必须满足权限和启动顺序才能真正绑定。
- Oracle 必须设
use_large_pages=only（不能是auto），且启动用户ulimit -l要设为unlimited（写进/etc/security/limits.conf后需重新登录生效） - PostgreSQL 9.6+ 需配
huge_pages = on，但前提是共享内存段（shared_buffers）能被整除进大页大小；例如shared_buffers = 8GB，2MB 页就得刚好是 4096 页，差 1 页都会 fallback - 两者都依赖
shmmax≥ 总共享内存大小，否则ipcs -lm里能看到限制值卡住
透明大页（THP）和标准 HugePages 能共存吗
能共存，但生产环境必须关掉 THP，否则它会干扰显式 HugePages 的行为。
- 检查命令：
cat /sys/kernel/mm/transparent_hugepage/enabled，输出含[never]才安全 - 关闭方法：
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled，并写入/etc/rc.local或 systemd service 保证开机生效 - 原因：THP 是动态合并小页，而 Oracle/PG 等要求内存全程锁定、不可 swap、不可迁移；THP 的后台扫描线程可能触发 page migration，导致大页失效
真正难的不是配参数，而是验证“进程地址空间里哪一块内存实际走了 2MB 页表项”。很多人停在 HugePages_Total 有数值就以为成了，结果性能没提升——因为 smaps 里全是 MMUPageSize: 4。
