Linux怎么查看进程的内存页大小 Linux下HugePages大页配置详解

为什么 echo 1024 > /proc/sys/vm/nr_hugepages 成功了，但进程还是分配失败

这恐怕是最让人困惑的地方：命令执行没报错，但大页就是没分配出来。关键在于理解，向/proc/sys/vm/nr_hugepages写入数字，只是向内核提交了一份“采购申请单”，而非“立即到货”。

内核需要从物理内存的“伙伴系统”中，找到连续的、未被分割的2MB内存块来兑现这份申请。如果系统已经运行了很长时间，内存碎片化严重，即使free -h显示还有大量空闲内存，也可能找不出足够的连续空间。这时，内核通常会选择静默失败——你的申请被接受了，但无法履行。

• 典型症状就是，执行命令后，HugePages_Free的数量纹丝不动，或者只零星增加几页。
• 解决之道通常只有两条：要么在系统启动之初、内存还非常“整洁”的时候，通过修改GRUB内核参数进行静态预留；要么就在服务器刚启动后，趁碎片还没产生，立即执行预留命令，然后再启动你的关键服务。

Oracle/PostgreSQL 这类服务启用 HugePages 的关键卡点

对于Oracle、PostgreSQL这类复杂的数据库服务，系统预留出大页只是万&里长征第一步。服务进程自身还需要满足一系列严苛的条件，才能成功绑定并使用这些大页。

• Oracle数据库：光在系统层面配好还不够。必须在Oracle的参数文件中明确设置use_large_pages=only（使用auto模式可能在某些情况下回退）。同时，启动Oracle的操作系统用户，其锁定内存限制（ulimit -l）必须设置为unlimited。这个限制通常在/etc/security/limits.conf中配置，修改后需要用户重新登录才能生效，这一点常常被忽略。
• PostgreSQL（9.6及以上版本）：需要在postgresql.conf中设置huge_pages = on。但这里有个精确的数学要求：shared_buffers（共享缓冲区）的大小，必须能被单个大页的大小（如2MB）整除。例如，shared_buffers = 8GB，使用2MB页时，恰好需要4096页。如果计算有丝毫偏差，PostgreSQL就会退而使用普通小页。
• 通用前提：无论是哪种数据库，都需要确保系统的共享内存上限（shmmax）大于或等于数据库所需的总共享内存大小。否则，用ipcs -lm命令查看时，会发现限制值成了拦路虎。

透明大页（THP）和标准 HugePages 能共存吗

从技术上讲，它们可以共存。但对于追求极致稳定性和确定性的生产环境，尤其是运行Oracle、PostgreSQL的数据库服务器，行业内的最佳实践是彻底关闭透明大页（THP）。

• 你可以通过cat /sys/kernel/mm/transparent_hugepage/enabled来检查其状态。输出中包含[never]才算安全。
• 关闭命令很简单：echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled。但务必记得将这个配置写入/etc/rc.local或相应的systemd服务单元，以确保重启后依然有效。
• 为什么要关闭？THP的本意是好的，它试图自动将零散的小页合并成大页。但这种动态行为与数据库的需求背道而驰。数据库需要的是锁定在物理内存中、不可交换（swap）、不可迁移的稳定大页。THP的后台合并和迁移机制，可能会无意中破坏这种稳定性，甚至导致预期中的大页失效，性能不升反降。

说到底，配置HugePages最难的部分，往往不是敲入那几条命令，而是事后严谨的验证。很多人止步于看到HugePages_Total有了数值，便以为大功告成。直到性能问题重现，回头仔细检查smaps，才愕然发现满屏的MMUPageSize: 4——原来，进程压根没跑在快车道上。这份细致，才是调优成功与否的分水岭。