透明大页（Transparent Huge Pages，简称THP）是Linux内核从2.6.38版本引入的内存管理特性，它允许内核自动将连续的4KB普通页合并为2MB的大页，从而减少页表项数量、降低TLB缺失率。这个设计初衷是提升性能，但在MySQL、MongoDB、Redis以及低延迟交易系统等场景中，THP却经常被认定为延迟抖动的元凶，各大数据库官方文档甚至直接建议关闭它。为什么一个加速机制反而会拖慢系统？本文从原理、模式选择到具体操作，完整讲解如何安全地禁用THP。
THP为什么会造成内存延迟波动
要理解THP的负面影响，需要先看它的工作方式。当THP模式设为always时，内核中有一个名为khugepaged的后台线程会持续扫描进程的地址空间，寻找可以合并成2MB大页的机会。这个扫描和整理动作本身会持有锁、触发页表迁移，过程中可能让正在访问相关内存的进程短暂停顿。
更关键的问题在于内存整理（memory compaction）。要构造一个连续的2MB物理区域，内核必须把零散分布的页面搬家，腾出连续空间。当系统内存碎片化严重时，khugepaged会反复尝试整理，导致某些线程出现毫秒级甚至更长的停顿。对于要求P99延迟稳定的服务来说，这种偶发的停顿就是典型的长尾来源。
此外还有写时复制的放大效应。以Redis的fork场景为例，fork后子进程与父进程共享内存页，如果这些页是2MB大页，哪怕只修改其中几个字节，内核也不得不复制整整2MB的物理内存，导致内存用量和拷贝开销显著放大。Redis官方文档明确指出，THP开启时fork延迟和内存占用都可能恶化，推荐关闭。
三种运行模式的区别与选择
通过内核参数/sys/kernel/mm/transparent_hugepage/enabled可以查看和设置THP的模式，它有三个取值：
cat /sys/kernel/mm/transparent_hugepage/enabled # 输出示例：[always] madvise never，方括号表示当前生效的模式
always表示内核对所有进程的匿名内存都尽力启用大页，khugepaged会积极介入。这是延迟敏感型应用最需要避开的模式。madvise则只对显式调用madvise(addr, len, MADV_HUGEPAGE)的内存区域启用大页，其他进程完全不受影响，是一种折中方案，适合部分自研程序能主动申请大页而其余服务追求稳定的混合场景。never彻底禁用THP，所有内存都按4KB页管理，行为最可预测。
一般建议是：数据库、缓存服务、虚拟化宿主机以及延迟敏感的Java应用直接选never；如果你的程序明确针对大页做过优化（比如某些大数据计算引擎），可以用madvise精细控制。需要注意THP与显式Hugetlbfs大页是两回事，禁用THP不影响通过vm.nr_hugepages预留的传统大页。
运行时临时禁用的操作步骤
临时修改只需向sysfs接口写入目标模式，立即生效，无需重启：
# 设置为完全禁用 echo never > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/transparent_hugepage/defrag # 验证修改结果 cat /sys/kernel/mm/transparent_hugepage/enabled # 输出应为：always madvise [never]
其中defrag接口控制内存碎片整理的激进度，建议一并处理。设置为never可以彻底停止khugepaged的合并整理行为。如果系统上运行着systemd管理的服务，还可以用tuned工具切换到throughput-performance之外的profile，例如latency-performance，它默认就会关闭THP：
tuned-adm profile latency-performance tuned-adm active # 查看当前生效的profile
临时方式在重启后会恢复默认值，适合先验证THP是否真的是延迟问题的根因。建议在修改前后分别压测，观察P99延迟和context switch、compact_stall等指标的变化，用数据确认效果。
通过GRUB永久禁用THP
要长期生效，最可靠的方式是修改GRUB配置，把参数传给内核启动项。编辑/etc/default/grub，在GRUB_CMDLINE_LINUX中加入如下内容：
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=centos/root rhgb quiet transparent_hugepage=never"
保存后根据发行版重新生成GRUB配置。CentOS或RHEL执行grub2-mkconfig -o /boot/grub2/grub.cfg，Debian或Ubuntu执行update-grub，然后重启系统。重启后再次检查：
cat /sys/kernel/mm/transparent_hugepage/enabled # 期望输出：always madvise [never] # 也可以通过dmesg确认启动参数已被内核接收 dmesg | grep -i huge
部分云主机无法直接改GRUB，可以改用rc.local或systemd服务，在系统启动早期执行前面提到的echo命令，同样能达到效果。一些软件（如Oracle RAC的预检查）会明确要求THP处于disabled状态，部署前提前配置好可以省去不少排查时间。
总结与验证建议
禁用THP并非万能优化，它牺牲了部分大页带来的TLB收益，换来的是延迟的可预测性。判断是否需要禁用，可以关注两个信号：一是/proc/vmstat中的thp_fault_alloc和compact_stall计数持续增长，二是压测中出现无明显原因的周期性延迟尖刺。满足这两点，将模式调整为never或madvise，再做对比压测，多数情况下长尾延迟都会得到明显改善。