跳转到主要内容

huge_pages

控制 PostgreSQL 在受支持操作系统上为主共享内存区域使用显式大页。
说明

Fact — 官方简述译文：控制在 Linux 或 Windows 上使用大页。

身份

类型 值enum
上游 pg_settings 类型
Context 值postmaster
修改后需要重启数据库
单位 值—
原始单位
范围 值—
最后在档版本的原始上下限
枚举值 值off, on, try
非枚举类型记为 —
分类 值Resource Usage / Memory
上游分类
最后 boot 值 值try
try

生命周期

Fact 值
首次观测 PG9.4
在档版本 PG9.4–19 Beta 3
移除版本 否
引入提交 f8ce16d0d264 — Rename huge_tlb_pages to huge_pages, and improve docs.
提交日期 2014-03-03
Discussion —

默认值变迁

PG9.0–19 Beta 3 实测 boot 默认值
版本 原始 boot_val 单位 人类可读值
PG9.4–19 Beta 3 try — try

机制详解

huge_pages 只影响主共享内存区域，并仅在服务器启动时评估。try 会申请大页，失败后回退普通页；on 会让申请失败直接阻止启动；off 则不发起申请。

显式大页可以减小页表并减少内存管理消耗的 CPU 时间，对较大的连续共享内存尤其有意义。在 Linux 上，PostgreSQL 要求 shared_memory_type=mmap 且操作系统预留足够大页；huge_pages_status 显示实际结果。

显式 HugeTLB 大页不等于 Linux 透明大页（THP）。PostgreSQL 文档在说明显式大页可能有益的同时，仍指出某些 Linux 版本上的 THP 可能导致性能下降。

调优建议

提示

Advice。 以下建议是工作负载起点，必须用真实测量验证。

场景 建议
OLTP 验证操作系统预留和 huge_pages_status 期间使用 try。只有在大页申请失败本就应该阻止启动、且跨重启预留可靠时，才改为 on。
OLAP 较大的共享内存可能受益更多，但应先计算所需页数，并为后端、查询工作区与操作系统留出内存；不要把大页视作必然提高吞吐量。
小规格 保留 try，或在大页预留的运维复杂度高于收益时使用 off。没有完整内存预算时，不要在小主机上预留很大比例。

Pigsty 取值

以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。

模板 有效值 与上游 boot 比较 源表达式
OLTP try 等于 boot 值 try
OLAP try 等于 boot 值 try
CRIT try 等于 boot 值 try
TINY try 等于 boot 值 try
注意

Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG9.4–19 Beta 3 = try (dcs)；OLAP: PG9.4–19 Beta 3 = try (dcs)；CRIT: PG9.4–19 Beta 3 = try (dcs)；TINY: PG9.4–19 Beta 3 = try (dcs)。 建议（待人工复核）——编辑推断：这样在节点已预留大页时可机会性使用，在大页不可用时仍保证启动；操作系统层的大页预留策略需要另行复核。

常见坑

  • 把显式大页与透明大页 THP 混为一谈。
  • 没有预留足够大页就设置 on，导致 PostgreSQL 无法启动。
  • 误以为它覆盖 work_mem 或其他普通进程内存；它针对主共享内存区域。
  • 只检查配置值，却不检查运行时 huge_pages_status。

huge_page_size · huge_pages_status · shared_buffers · shared_memory_type · min_dynamic_shared_memory

参考资料

最后修改 2026-09-11