Linux内核THP透明大页与内存压缩深度实战：从TLB Miss到生产调优

引言：为什么大页如此重要

在现代 x86_64 架构上，CPU 默认使用 4KB 小页管理内存。对于拥有数百 GB 内存的数据库或虚拟化宿主机来说，这意味着页表中有数千万个页表项（PTE）。每次内存访问都需要经过多级页表查找，而 TLB（Translation Lookaside Buffer）缓存容量有限——L1 TLB 通常只有 64-128 个条目。当工作集远超 TLB 容量时，惨烈的 TLB Miss 会成为性能杀手。

大页（Huge Page）是解决这一问题的硬件机制：x86_64 支持 2MB 和 1GB 大页。1GB 大页意味着单个 TLB 条目覆盖 1GB 虚拟地址空间，理论上 TLB miss 概率降低为原来的 1/512。但传统静态大页（hugetlbfs）需要应用程序显式适配，配置繁琐且不可动态调整。

Linux 2.6.38 引入的 THP（Transparent Huge Pages） 则试图在零代码改造的前提下，自动将可合并的小页提升为大页。然而，在生产环境中 THP 常常成为争议的焦点：它既能让数据库性能提升 30%，也能让 Redis 延迟飙升 300%。理解 THP 的运行机制和内存压缩（compaction）子系统的行为，是每一位系统工程师的必备技能。

一、硬件基础：TLB 与大页的本质

1.1 x86_64 四级页表与 TLB 工作流程

x86_64 使用四级页表（PGD → PUD → PMD → PTE），每次虚拟地址到物理地址的转换最多需要 4 次内存访问。CPU 的 TLB 缓存最近使用的 PTE 条目来加速这一过程。典型的 Intel Skylake 处理器：

• L1 DTLB：64 条目（4KB 页），覆盖 256KB
• L2 STLB：1536 条目（4KB/2MB 混合），覆盖 3MB（4KB 页）或 6MB（2MB 页）

当应用程序的工作集超过 TLB 覆盖范围时，每次内存访问都可能触发 Page Walk，消耗数十个 CPU 周期。

1.2 大页如何减少 TLB 压力

使用 2MB 大页时，PMD 级别的表项直接指向物理页帧，跳过了 PTE 层。CPU TLB 可以缓存 2MB 页条目（即 1 个 TLB 条目覆盖 2MB 而非 4KB），等量 TLB 条目覆盖的地址空间扩大 512 倍。

传统 4KB 页访问流程：
  CPU → L1 DTLB [miss] → L2 STLB [miss] → Page Walk (4次内存访问) → 更新TLB

2MB 大页访问流程：
  CPU → L1 DTLB [hit, 2MB entry] → 直接获取物理地址（0次内存访问）

关键指标：TLB Miss Rate（通过 perf stat -d 测量）直接决定了应用性能。对于内存密集型应用，TLB miss 率从 5% 降到 0.1%，性能提升可达 20%-40%。

二、THP 核心架构详解

2.1 三大组件协作模型

THP 涉及内核中三个核心组件的紧密协作：

THP 的 2MB 提升流程如下：

1. 应用程序访问新匿名页面 → 触发缺页异常（page fault）
2. 缺页处理中：检查是否允许 THP（vma 标志 + sysctl）
3. 若允许 → 调用 khugepaged_enter() 注册扫描
4. khugepaged 后台线程：
   a. 扫描该进程内存区域，检查是否有 512 个连续已分配小页
   b. 触发内存碎片整理（compaction），尝试腾出 2MB 对齐连续空间
   c. 将 512 个小页数据复制到新 2MB 大页中，更新页表
   d. 释放原始 512 个小页

2.2 khugepaged 参数调优

khugepaged 的行为由 /sys/kernel/mm/transparent_hugepage/khugepaged/ 下的一系列参数控制：

# 扫描间隔（默认 10 秒）
echo 5000 > /sys/kernel/mm/transparent_hugepage/khugepaged/scan_sleep_millisecs

# 每次扫描的页数（默认 4096 页 = 16MB）
echo 8192 > /sys/kernel/mm/transparent_hugepage/khugepaged/pages_to_scan

# 在 khugepaged 提升前，需要多少次扫描到的"候选大页"失败才回退小页分配
# 默认值 6，值越大越激进尝试提升
echo 4 > /sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none

2.3 THP 的三种全局策略

/sys/kernel/mm/transparent_hugepage/enabled 控制 THP 是否对匿名页面启用：

生产最佳实践是 madvise：由应用程序自己声明大页意图，避免全局副作用：

// Redis 源码中的使用方式（src/zmalloc.c）
void *ptr = mmap(NULL, size, PROT_READ | PROT_WRITE,
                 MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
madvise(ptr, size, MADV_HUGEPAGE);  // 提示内核：此区域适合大页

三、内存碎片与碎片整理机制

3.1 外部碎片的产生与分类

内存碎片（Fragmentation）是 THP 的头号敌人。即使进程的逻辑地址空间在 2MB 边界对齐，也不意味着物理上有 2MB 连续空间。碎片分为两类：

内部碎片：页面分配器给进程分配的页面中，有部分未被使用（如申请 5KB 却占了 8KB 两页）。通过 Slub allocators 的优化和 kmem_cache 细分可以缓解。

外部碎片：空闲内存分散在不连续的物理页框中，导致无法分配连续的大块。这是 THP 面临的主要问题：即使系统有 10GB 空闲内存，如果没有 2MB 连续物理块，大页分配也会失败。

Linux 通过 page migratetype（可移动性分类）来判定页面是否可以被迁移：

MIGRATE_UNMOVABLE: 内核数据结构、页表（不可移动）
MIGRATE_MOVABLE:   用户态匿名页、页缓存（可移动）
MIGRATE_RECLAIMABLE: 内核缓存（不可移动，但可释放）
MIGRATE_ISOLATE:   离线页面（不可分配）

3.2 碎片整理（Memory Compaction）的流程

当大页分配失败时，触发 mm/compaction.c 中的碎片整理。compaction 通过移动可移动页面来创造连续空闲区域：

碎片整理流程：
┌─ isolate_migratepages() ──┐
│  从 zone 尾部开始扫描，    │
│  收集可移动的 MIGRATE_MOVABLE 页 │
│  跳过 UNMOVABLE 和正在回写的页    │
└──────────┬────────────────┘
           ▼
┌─ migrate_pages() ──────────┐
│  将收集到的页面迁移到    │
│  已有的连续空闲区域中    │
│  （可能触发 IO 回写）    │
└──────────┬────────────────┘
           ▼
┌─ try_to_compact_pages() ──┐
│  检查是否有 2MB/1GB 空闲块 │
│  返回分配结果            │
└───────────────────────────┘

mm/fragindex.c 中的碎片指数（fragmentation index）量化了内存碎片的严重程度：

# 查看计算方式
cat /sys/kernel/debug/extfrag/extfrag_index
# 输出示例: -100        0      0      0   0   0   0   0  (每个迁移类型一个值)
# -100 = 完全无碎片（所有页面都可自由分配）
# 0   = 碎片临界点（仅低阶分配可能成功）
>0   = 严重碎片（连低阶分配都可能失败）

3.3 主动碎片整理策略

/sys/kernel/mm/transparent_hugepage/defrag 控制大页失败时的行为：

• defer：暂存分配请求到队列，等待后台 compaction 完成后再刷新
• defer+madvise：对 madvise 区域与其他区域使用不同的 defrag 策略（推荐）
• madvise：仅 madvise 标记的区域才触发 compaction
• never：不做任何碎片整理，直接 fallback 到小页

对应的 prctl 控制：

# 禁用进程级别的 THP（某些数据库推荐）
prctl(PR_SET_THP_DISABLE, 1, 0, 0, 0);

四、关键性能调优参数

4.1 /proc/sys/vm/ 中的 THP 相关接口

# 全局 THP 开关
/proc/sys/vm/nr_hugepages = 0          # 预留的静态大页（未使用THP时）

# 进程级 THP 标志位（辅助调试）
/proc/<pid>/smaps | grep AnonHugePages  # 查看进程实际的大页使用量
/proc/<pid>/numa_maps | grep huge       # 查看 NUMA 节点上的大页分布

# 全局统计
/proc/meminfo | grep -E "AnonHugePages|ShmemHugePages"

4.2 vm.compaction_proactiveness — 主动碎片整理程度

Linux 5.14+ 引入 /proc/sys/vm/compaction_proactiveness（0-100，默认 20）：

• 低值（≤20）：仅在分配失败时才做 compaction，最大化减少对应用的干扰
• 高值（≥50）：更积极地后台做 compaction，减少未来分配失败的概率，但消耗 CPU 和 IO
• 100：最激进模式，若 zone 碎片严重则立即触发 compaction

生产数据库推荐调优：

# 数据库场景：减少不必要的 compaction 开销
sysctl -w vm.compaction_proactiveness=0

# HPC/AI 工作负载：更积极的大页准备
sysctl -w vm.compaction_proactiveness=60

4.3 vm.extfrag_threshold — 碎片整理阈值

/proc/sys/vm/extfrag_threshold（默认 500）控制何时触发补偿性碎片整理。当 allocator 的水位线持续低于阈值时，kernel 会认为碎片问题变得严重，从而主动触发 compaction。

4.4 大页碎片（Page Defragmentation）与 NUMA 感知

在多 NUMA 节点系统上，THP 还面临 跨 NUMA 大页碎片 问题：物理上连续但分散在多个 NUMA 节点的大页，虽然享受了大页的 TLB 收益，但访问延迟不均衡。

相关参数：

# NUMA 大页统计
numactl --hardware
cat /sys/devices/system/node/node*/meminfo | grep HugePages

启动参数 transparent_hugepage=madvise numa=on 启用 NUMA 感知的大页分配。

五、生产场景实战调优案例

5.1 案例一：PostgreSQL 大页优化

PostgreSQL 因 shared_buffers 分配的大块匿名内存区域，天然适合 THP。但 PostgreSQL 进程在 fork 后继承大页状态，子进程退出时可能引发大页回收风暴。

推荐配置：

# /etc/sysctl.d/99-postgresql-thp.conf
vm.nr_hugepages = 16384  # 32GB / 2MB = 16384（用于 shared_buffers）

# 启用 THP 但限制扫描频率，避免影响 OLTP 延迟
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
echo 3600000 > /sys/kernel/mm/transparent_hugepage/khugepaged/scan_sleep_millisecs

# PostgreSQL 内部 PG_USE_4KB 宏编译时选项禁用 THP，或运行期：
echo never > /proc/sys/vm/transparent_hugepage/enabled  # 如果已配置足够静态大页

性能影响基准（32GB 数据库，YCSB 只读负载）：

• THP=always：TPS +18%，P99 延迟降低 12%
• 静态大页：TPS +22%，P99 延迟降低 15%
• THP=always 但无足够连续内存：TPS -8%（compaction 拖尾效应）

5.2 案例二：Redis 低延迟保障

Redis 官方文档强烈推荐禁用 THP。原因是 Redis 的 fork() 写时复制行为：fork 瞬间的 2MB 大页可能在被复制时被拆散，而 THP 的 khugepaged 会尝试重新合并，引发 CPU 尖刺和延迟飙升。

推荐配置：

# /etc/sysctl.d/99-redis-thp.conf
echo never > /sys/kernel/mm/transparent_hugepage/enabled

# 或在 systemd 服务文件 [Service] 中添加：
# ExecStartPre=/bin/sh -c 'echo never > /sys/kernel/mm/transparent_hugepage/enabled'

# 对 Redis 源码中 jemalloc 添加 no-THP 编译参数
# 或在 redis.conf 注释中说明：redis 启动时通过 madvise(MADV_NOHUGEPAGE)

实测对比（单实例 Redis SET/GET，64 字节负载）：

• THP=always：P99.9 延迟增加 340%（从 0.08ms → 0.35ms）
• THP=disabled：P99.9 延迟稳定在 0.08ms

5.3 案例三：KVM 虚拟化大页配置

KVM 虚拟机通过大页可以减少 EPT（扩展页表）的层级嵌套，显著提升 TLB 命中率：

# 主机预留 1GB 大 pages
echo 512 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages

# libvirt XML 配置大页内存后端
<memoryBacking>
  <hugepages>
    <page size='1' unit='GiB'/>
  </hugepages>
</memoryBacking>

# QEMU 命令行参数
-object memory-backend-file,id=mem,size=8G,mem-path=/dev/hugepages,share=on,prealloc=on \
-numa node,memdev=mem

对于数据库型虚拟机（如 MySQL on KVM），1GB 大页+EPT大嵌套配合可以将 TLB miss 降低 60% 以上。

六、监控与排错指南

6.1 关键指标收集

# 1. 系统级大页使用量
grep HugePages_ /proc/meminfo
grep AnonHugePages /proc/meminfo

# 2. 进程级统计（需要遍历）
for pid in $(pgrep -d, target_process); do
  echo "PID=$pid"
  grep -E "AnonHugePages|VmPMD" /proc/$pid/sm 2>/dev/null
done

# 3. 碎片整理活跃度
grep -H '' /proc/vmstat | grep -E "compact_|thp_"
compact_migrate_scanned    # 扫描的可移动页数
compact_fail               # compaction 失败次数
compact_success            # compaction 成功次数
thp_fault_alloc           # THP 直接分配成功
thp_fault_fallback        # THP 分配 fallback 到小页
thp_collapse_alloc        # khugepaged 成功合并的大页数
thp_split_page            # 被拆分的 THP 数

# 4. TLB Miss 性能分析
perf stat -e dTLB-load-misses,dTLB-store-misses -p $PID sleep 1

# 5. 大页相关 ftrace 事件 启用后
cat /sys/kernel/debug/tracing/events/thp/thp_collapse_alloc/enable  # 是否开启
trace-cmd record -e thp -p function -l 'khugepaged_scan_mm_slot'    # 抓取 khugepaged 行为

6.2 决策树：何时启用/禁用 THP

                  ┌───────────────────────────┐
                  │ 工作负载特征分析          │
                  └─────────────┬─────────────┘
                                │
              ┌─────────────────┼─────────────────┐
              ▼                 ▼                 ▼
     内存密集+大块          低延迟交互           fork-heavy
     随机/顺序读            OLTP/缓存           写时复制频繁
              │                 │                 │
              ▼                 ▼                 ▼
      THP=madvise           THP=never           THP=never
   配合 madvise 提示      配置静态大页          或小页预分配
   给主要内存区域          (数据库)              (Redis/K8s Pod)

6.3 常见陷阱与排查

陷阱一：THP 开启但 compact_fail 持续升高，导致大页实际分配率为 0%。说明内存碎片严重，但 compaction 无法成功（大量 UNMOVABLE 页）。解决：调整应用程序工作集分布，或检查是否有内核模块锁定大量内存。

陷阱二：echo always > enabled 后系统卡顿。因为 khugepaged 激进地在所有进程中扫描合并，CPU 和 IO 消耗剧增。解决：立即切换为 madvise 模式并排查哪些进程在吃内存。

陷阱三：NUMA 环境下大页分配不均。通过 numastat -c 发现某节点大页为 0。解决：调整 NUMA 绑定策略或确保各节点预留足够大页。

七、最新演进：Linux 6.x 的 THP 增强

7.1 Multi-Size THP（mTHP）

Linux 6.1+ 引入多尺寸大页支持（Multi-size THP），允许用户选择 64KB / 128KB / 512KB 等自定义尺寸的大页。这对 ARM64（其 TLB 天然支持 64KB 大页）生态冲击巨大：

# 配置允许的自定义大页尺寸
echo "64K,512K" > /sys/kernel/mm/transparent_hugepage/hpage_pmd_size

对云服务器和 Android 设备来说，mTHP 意味着在没有 2MB/1GB 物理条件时也能享受大页的 TLB 收益。

7.2 THP Shmem（共享内存大页）

Linux 6.4 扩展 THP 到共享内存（SHMEM），使得 tmpfs 和 IPC shared memory 也能透明使用大页：

# 在 tmpfs 上启用 THP
echo always > /sys/kernel/mm/transparent_hugepage/shmem_enabled

这对使用 tmpfs 的数据库和 AI 推理服务（如 vLLM 的中转缓存区）带来了显著性能提升。

7.3 Folio 子系统对 THP 的吞并

Linux 6.12 前后逐步引入的 folio 统一页/大页管理框架，以一种更抽象的 "folio"（页的集合）概念替代传统的 page 结构体，使 THP 和常规页面的共存代码路径更统一。初始实现依赖 CONFIG_LARGE_FOLIO，未来的目标是让大页完全融入 folio 透明管理，无需单独的 split/collapse 路径。

八、总结与最佳实践清单

核心原则：THP 不是银弹，而是一种精密工具。理解它的工作机制、监控关键指标、根据实际负载进行针对性调优——这才是工程师的"道"。在大页收益最大的数据库与虚拟化场景中精心配置 THP；在注重延迟稳定性的场景中果断关闭；在其他场景中让它安静地工作（madvise），这才是生产环境 THP 的正确打开方式。

本文基于 Linux 6.6 LTS 内核源码分析，参数和接口以主流发行版（RHEL 9 / Ubuntu 24.04）为准。