Linux THP 与 Redis 禁用 THP 的原因分析

PeterLi
4 阅读16分钟

引言

如果你翻阅过任何一份 Redis 生产环境最佳实践文档，一定会看到一条硬性要求：必须禁用 Linux 的 THP（透明巨页）特性。很多同学照着配置做了，却始终没搞懂：THP 明明是 Linux 内核推出的内存性能优化特性，为什么到了 Redis 这里就成了 “性能杀手”？禁用它的底层逻辑到底是什么？

今天这篇文章，我们就从内存分页的基础原理讲起，一步步拆解 THP 的工作机制，再结合 Redis 的核心架构，把 “Redis 为什么必须禁用 THP” 这个问题讲透，让你不仅知其然，更知其所以然。

一、先搞懂基础：Linux 内存分页与 TLB 的本质

要理解 THP，首先要搞清楚 Linux 操作系统的内存分页机制 —— 这是所有内存管理的核心基础。

我们知道，程序运行时使用的是虚拟内存地址，而 CPU 真正访问内存需要的是物理内存地址，这中间的地址翻译工作，由 CPU 内置的 MMU（Memory Management Unit，内存管理单元）负责。为了高效管理内存，Linux 把物理内存划分为一个个固定大小的 “块”，这个最小管理单元就是页（Page） ，x86 架构下默认的页大小是4KB。

MMU 翻译地址时，需要查询存储在内存中的页表—— 页表记录了每一个虚拟页对应的物理页地址。这里就出现了一个很现实的问题：如果服务器内存是 16GB，按 4KB 一页划分，就会产生 400 多万个页表项。MMU 不可能每次地址翻译都去内存里遍历这几百万条记录，否则内存访问的性能会直接崩塌。

为了解决这个问题，CPU 在 MMU 里内置了一个高速缓存，叫做TLB（Translation Lookaside Buffer，地址转换旁路缓冲） 。你可以把 TLB 理解成翻译官的随身速记本，专门存放最近最常用的 “虚拟地址 - 物理地址” 映射关系。TLB 的访问速度和 CPU 寄存器相当，只要命中 TLB，地址翻译就能在 1 个时钟周期内完成；但如果 TLB 未命中，就必须去内存里查询多级页表，耗时会放大几十甚至上百倍。

很明显，TLB 的命中率直接决定了内存访问的性能。但 TLB 的存储空间极其有限，一般只能存放几千条页表映射。对于大内存应用来说，4KB 的小页会导致页表项爆炸式增长，TLB 命中率极低，大部分内存访问都要走慢速的页表查询，这就是传统小页机制的核心性能瓶颈。

我们可以用图书馆做个通俗的比喻：

  • 4KB 的小页就像一本只有 4 页的薄书，16GB 的内容需要 400 多万本这样的薄书；
  • TLB 就是图书馆前台的检索目录，只能放下几千条书目记录；
  • 大部分时候你要找书，前台目录里查不到，只能跑到库房里翻厚厚的多级总目录，效率极低。

二、THP 是什么？内核为你 “自动优化” 的巨页机制

为了解决小页带来的 TLB 命中率问题，Linux 内核很早就推出了巨页（Huge Page） 机制：把原本 4KB 的页放大，x86 架构下默认支持 2MB 的巨页，甚至 1GB 的超大页。

还是用刚才的图书馆比喻：2MB 的巨页就相当于把 512 本 4KB 的薄书装订成一本厚书。原本需要 512 条目录记录才能覆盖的内容，现在 1 条就够了。16GB 的内存只需要 8192 个 2MB 巨页，完全可以全部放进 TLB 缓存里，TLB 命中率提升巨大，地址翻译的开销大幅降低。

但传统的巨页机制有个致命的缺点：使用门槛极高。它需要开发者手动在代码里申请、管理巨页，还要提前预留固定的巨页内存，对普通应用和开发者极不友好，很难普及。

于是，Linux 内核在 2.6.38 版本正式合入了THP（Transparent Huge Pages，透明巨页） 特性，并在 3.10 之后的版本默认开启。它的核心设计目标就是透明化、自动化：无需开发者做任何代码修改，无需手动配置，内核会自动为应用程序分配和管理巨页，让所有应用都能无痛享受到巨页带来的性能收益。

THP 的核心工作原理可以概括为 3 点：

  1. 优先分配巨页：应用申请内存时，内核会优先尝试分配连续的 2MB 物理巨页；
  2. 内存规整兜底：如果当前物理内存没有足够的连续 2MB 空间，内核会触发内存规整（memory compaction）—— 把零散的物理页移动整理，腾出连续的大块内存，尽可能满足巨页分配；
  3. 后台自动合并：内核会启动一个名为khugepaged的常驻线程，定期扫描进程的地址空间，把已经分配的、符合条件的 4KB 普通页，自动合并成 2MB 巨页，哪怕申请时没拿到巨页，后续也能自动升级。

从设计初衷来看，THP 绝对是个 “好心” 的特性：它把巨页的使用门槛降到了 0，让数据库、大数据计算等大内存应用，不用做任何改造就能获得性能提升。但理想很丰满，现实却很骨感 ——THP 的 “透明” 和 “自动”，恰恰为延迟敏感型应用埋下了巨大的性能隐患。

三、理想很丰满，现实很骨感：THP 的隐藏副作用

THP 的所有问题，都源于它的 “自动化” 和 “无感知”。内核为了帮你 “优化” 性能，会在你完全不知情的情况下，执行很多耗时的后台操作，带来不可控的延迟抖动和额外开销。

我们先拆解 THP 最核心的 3 个副作用，这也是后续 Redis 问题的根源：

1. 内存分配的同步阻塞，带来延迟尖峰

当应用申请内存，内核无法直接拿到连续的 2MB 巨页时，会触发内存规整操作。这个操作就像你要在摆满零散小书的书架上，腾出一个连续的大格子放厚书，必须把所有零散的小书挪到一起，这个过程非常耗时，尤其是在内存碎片化严重的场景下，规整操作可能会消耗几毫秒甚至几十毫秒的 CPU 时间。

更致命的是，这个规整操作是同步执行的，会直接阻塞当前应用的内存申请调用。也就是说，你的应用正在处理核心业务，突然因为申请内存被内核卡住，必须等内存规整完成才能继续执行，延迟尖峰就这么来了。

2. 后台合并线程，带来无规律的异步阻塞

khugepaged内核线程是 THP 的 “自动优化核心”，但也是最坑的 “定时炸弹”。它会定期（默认每 10 秒）扫描进程的地址空间，把符合条件的普通页合并成巨页。

这个合并操作有两个致命问题：

  • 合并过程需要给对应的内存区域加锁，此时如果应用进程要访问这段内存，会被直接阻塞；
  • 合并操作是内核异步触发的，你完全不知道它什么时候会执行，也无法控制。

这就导致应用会出现莫名其妙、毫无规律的延迟尖峰，排查起来极其困难 —— 你看遍了应用日志，找不到任何异常，却始终不知道是内核在背后偷偷 “搞优化”。

3. 放大的 IO 开销，swap 场景下的性能灾难

THP 的巨页是一个不可拆分的整体，哪怕一个 2MB 的巨页里，只有 4KB 的内容被访问过，内核也会把整个 2MB 当做一个单元来管理。

当系统内存不足触发 swap（内存交换到磁盘）时，这个特性会带来灾难性的后果：原本只需要把 4KB 的冷数据写到磁盘，现在必须把整个 2MB 的巨页全部写入，IO 量直接放大了 512 倍。对于磁盘 IO 本就敏感的应用来说，这会直接导致 IO 带宽被打满，应用响应速度急剧下降，甚至完全卡死。

四、核心拆解：Redis 为什么必须禁用 THP？

讲完了 THP 的原理和副作用，我们再结合 Redis 的核心架构和特性，就能彻底明白：THP 的设计初衷和 Redis 的核心需求完全相悖，它带来的收益微乎其微，却会把 Redis 的所有核心机制都拖入泥潭。

我们先回顾 Redis 的几个核心特性，每一个都和 THP 的副作用完美 “对冲”：

  1. 核心命令单线程执行，对延迟极其敏感，任何微秒级的阻塞都会被放大，影响所有请求的响应时间；
  2. 依赖 fork 子进程实现持久化，RDB 快照、AOF 重写都依赖 fork，而 fork 的性能核心是写时复制（Copy-On-Write，COW）机制；
  3. 随机内存访问模式，键值对增删改频繁，内存碎片化高，不存在大块连续内存的顺序访问；
  4. 对 P99/P999 延迟（100 / 1000 个请求里最慢的 1 个的大概耗时）有极高要求，生产环境完全无法接受无规律的延迟尖峰。

接下来我们逐一拆解，THP 到底会给 Redis 带来哪些致命问题。

1. 彻底击穿写时复制（COW）机制，内存与 CPU 开销暴增

这是 Redis 禁用 THP 最核心、最致命的原因。

Redis 为了实现不阻塞主线程的持久化，会 fork 子进程来生成 RDB 快照、执行 AOF 重写。fork 时，Linux 采用了写时复制（COW） 机制：父子进程共享同一份物理内存，只有当父进程（Redis 主线程）修改某一页内存时，内核才会复制这一页给父进程，子进程依然使用原来的页。

COW 的设计初衷，就是为了减少 fork 时的内存复制开销，让 Redis 在几十 GB 内存的场景下，也能快速完成 fork。而 THP 的出现，直接把这个设计初衷完全击碎了。

我们用一个最直观的例子来看：

  • 场景：Redis 实例内存占用 10GB，每秒处理 1000 个写请求（极端情况假设每个请求 Key 都极其分散，此时每个 Key 跨页），每个写请求修改 4KB 的内存数据。
  • 禁用 THP（4KB 小页）：每个写请求触发 1 次 4KB 页的复制，每秒复制总内存为 1000 * 4KB = 4000KB（大概4MB），CPU 和内存开销几乎可以忽略。
  • 开启 THP（2MB 巨页）：每个写请求修改的 4KB 数据，属于一个 2MB 的巨页，内核必须复制整个 2MB 的巨页，每秒复制总内存为 1000 * 2MB = 2000MB（大概 2GB）。

这是什么概念？内存复制开销直接放大了 512 倍！不仅会导致服务器内存带宽被瞬间打满，CPU 占用飙升，更严重的是：

  • 内存占用会急剧膨胀，原本 10GB 的实例，fork 后可能瞬间占用 20GB 以上的内存，极易触发 OOM killer，导致 Redis 进程被系统强制杀掉；
  • 巨页复制的耗时远大于小页，而这个复制操作是在 Redis 主线程中执行的，会直接阻塞主线程，导致所有命令的延迟大幅升高，甚至出现超时。

还是用通俗的比喻：COW 机制本来是 “你修改哪一页，就复印哪一页”，而 THP 把 512 页装订成了一本厚书，你改了其中一页，就得把整本 512 页全部复印一遍，费时费料，还耽误你正常干活。

2. 内存规整与分配阻塞，直接卡住 Redis 主线程

Redis 的核心命令执行、内存申请与释放，全部在主线程中完成。这意味着，主线程的任何阻塞，都会直接影响所有请求的响应时间。

而开启 THP 后，Redis 每次申请内存，内核都会优先尝试分配 2MB 巨页。当内存碎片化严重（Redis 频繁增删键值对是常态），没有足够的连续物理内存时，内核会触发同步的内存规整操作，直接阻塞 Redis 主线程。

对于 Redis 来说，哪怕是 1 毫秒的阻塞，都会导致上百个命令排队延迟；如果是几十毫秒的阻塞，甚至会触发主从切换、客户端超时断开等生产事故。而这种阻塞，会随着内存碎片化的加剧变得越来越频繁。

3. khugepaged 线程带来无规律的延迟尖峰，排查难度拉满

Redis 生产环境对 P99、P999 延迟有极高的要求，最忌讳的就是无规律、不可控的延迟尖峰。

而khugepaged内核线程的自动合并操作，恰恰就是这种 “定时炸弹”。它会定期扫描 Redis 的地址空间，合并普通页为巨页，合并时的加锁操作会阻塞 Redis 主线程对对应内存的访问。

最坑的是，这个操作是内核异步触发的，和 Redis 的业务峰值完全无关。你可能在凌晨低峰期，突然看到 Redis 延迟飙升，查遍了慢查询、CPU、IO、网络，都找不到任何原因，最后才发现是内核的khugepaged线程在背后 “优化” 内存。这种不可控的延迟，对于生产环境的 Redis 来说，是完全无法接受的。

4. Redis 的内存访问模式，完全享受不到 THP 的收益

THP 的性能收益，只有在大块连续内存、顺序访问的场景下才能体现出来，比如 Hadoop/Spark 大数据计算、批量数据导入等场景，这些场景能充分利用 2MB 巨页的连续空间，大幅提升 TLB 命中率。

但 Redis 的内存访问模式完全相反：它的键值对大小不一，增删改都是随机的，内存访问也是完全随机的，根本不存在大块连续内存的顺序访问。绝大多数场景下，Redis 根本享受不到 THP 带来的 TLB 命中率提升，反而要承担 THP 带来的所有阻塞、开销和延迟尖峰，完全是得不偿失。

五、实操指南：如何正确禁用 THP？

了解了原理之后，我们来看生产环境中，如何正确、彻底地禁用 THP，分为临时禁用和永久禁用两种方式。

前置检查：查看当前 THP 状态

首先执行以下命令，查看当前系统的 THP 状态：

# 主流发行版路径 
cat /sys/kernel/mm/transparent_hugepage/enabled 
# 老版本 RHEL/CentOS 路径，若上面的路径不存在，执行这个 
cat /sys/kernel/mm/redhat_transparent_hugepage/enabled

如果输出结果中，[always] 处于中括号内，说明 THP 处于默认开启状态；如果是[never]，说明已经禁用。

1. 临时禁用（重启后失效）

适合测试验证场景，无需重启服务器，执行以下命令即可：

# 禁用THP 
echo never > /sys/kernel/mm/transparent_hugepage/enabled 
# 禁用巨页碎片整理，必须同时关闭 
echo never > /sys/kernel/mm/transparent_hugepage/defrag

注意：如果是老版本 RHEL/CentOS，需要替换为对应的redhat_transparent_hugepage路径。

2. 永久禁用（重启后依然生效）

生产环境推荐使用这种方式，分为两种实现方案：

方案一：修改 GRUB 配置（最彻底，推荐）

这是最稳定、最彻底的禁用方式，直接在内核启动参数中关闭 THP：

  1. 编辑 GRUB 配置文件：
vi /etc/default/grub
  1. 在GRUB_CMDLINE_LINUX配置项的末尾，添加transparent_hugepage=never，示例如下：
GRUB_CMDLINE_LINUX="crashkernel=auto rhgb quiet transparent_hugepage=never"
  1. 重新生成 GRUB 引导配置：
# BIOS引导系统执行 
grub2-mkconfig -o /boot/grub2/grub.cfg 
# UEFI引导系统执行，不同发行版路径略有差异，以实际为准 
grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
  1. 重启服务器后生效。

方案二：修改 rc.local（无需重启，适合紧急场景）

如果服务器不能重启，可以通过 rc.local 开机自启脚本实现永久禁用：

  1. 编辑 rc.local 文件：
vi /etc/rc.d/rc.local
  1. 在文件末尾添加以下内容：
echo never > /sys/kernel/mm/transparent_hugepage/enabled 
echo never > /sys/kernel/mm/transparent_hugepage/defrag
  1. 给 rc.local 文件添加执行权限，否则开机不会执行：
chmod +x /etc/rc.d/rc.local
  1. 执行脚本立即生效，无需重启：
source /etc/rc.d/rc.local

禁用验证

执行完配置后，再次执行查看命令，确认输出结果中[never]处于中括号内，即为禁用成功：

cat /sys/kernel/mm/transparent_hugepage/enabled 
# 输出示例：always madvise [never]

六、总结

THP 是 Linux 内核为了降低大内存应用的地址翻译开销，设计的自动化巨页管理机制。它对于大块连续内存、顺序访问、对延迟不敏感的应用（如大数据计算、离线数仓），确实能带来明显的性能提升。

但对于 Redis 这种单线程延迟敏感、随机内存访问、强依赖 COW 机制的数据库来说，THP 的自动化特性完全是 “好心办坏事”：它不仅无法带来可感知的性能收益，还会导致主线程阻塞、延迟尖峰、内存开销暴增、OOM 风险升高等一系列致命问题。

这也是为什么 Redis 官方文档、所有云厂商的 Redis 最佳实践，都把 “禁用 THP” 作为生产环境的硬性要求。

最后要补充一句：技术没有绝对的好坏，只有适合不适合。我们不用因为 Redis 要禁用 THP，就否定这个特性的价值，而是要根据应用的内存访问模式、性能需求，选择是否开启。对于延迟敏感的在线业务系统，尤其是 Redis、MongoDB 这类 NoSQL 数据库，禁用 THP 永远是最稳妥的最佳实践。

avatar
文章
阅读
粉丝