Linux查看进程内存页大小及HugePages配置详解

本文深入解析了Linux中进程实际使用2MB大页（HugePages）的关键验证方法与常见误区，强调不能仅依赖/proc/meminfo中HugePages_Free的变化来判断生效与否，而必须通过/proc/[pid]/smaps精准检查MMUPageSize=2048且MMUPageOffset=0；同时系统性梳理了Oracle和PostgreSQL启用大页的核心条件（如use_large_pages=only、ulimit -l unlimited、shared_buffers整除大页大小）、动态分配失败的根本原因（物理内存碎片导致nr_hugepages静默失效），并明确指出透明大页（THP）必须禁用以避免干扰——真正决定性能提升的，是进程内存映射中每一块是否真实走2MB页表项，而非参数配置表面成功。

怎么确认进程是否真的用了2MB大页

光看 /proc/meminfo 里 HugePages_Free 变少了没用，很多场景下它减了，但目标进程根本没用上。真正要看的是进程自己的内存映射细节。

最直接的方式是查 /proc//smaps（把 换成实际进程号）：

• 搜索 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。

今天关于《Linux查看进程内存页大小及HugePages配置详解》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于Linux的内容请关注golang学习网公众号！