数据库服务器为何要关闭 Linux 透明大页（THP）

今天，我们不谈配置步骤，而是深入内核和数据库工作负载的层面，看看这个看似能提升性能的特性，为什么在数据库面前反而成了需要被关掉的“性能陷阱”。

THP 的设计初衷与美好愿景

透明大页是Linux内核提供的一种内存管理优化。它的目标很直接：减少TLB（Translation Lookaside Buffer）未命中的开销。简单来说，CPU通过虚拟地址访问内存，需要经过页表转换得到物理地址，这个过程如果每次都查完整的页表会很慢，所以CPU用TLB这个高速缓存来存最近用到的地址映射。TLB容量有限，如果程序要访问的内存地址非常分散（即使用了大量不同的4KB小页），TLB很快就装不下了，导致频繁的未命中，性能下降。

THP的思路是，内核自动将连续的512个4KB小页合并成一个2MB的大页。这样一来，一个TLB条目就能覆盖2MB的连续地址空间，大大提升了TLB的“命中范围”，理论上能提升那些需要访问大块连续内存的应用程序（如科学计算、某些图形处理）的性能。而且它对应用程序是“透明”的，应用无需修改代码就能享受潜在的好处。这听起来非常完美。

数据库的工作负载戳中了THP的软肋

问题出在“透明”和“自动”这两个词上。数据库的内存访问模式，与THP的优化假设存在根本性的冲突。

首先，数据库的内存使用是高度动态和碎片化的。以MySQL InnoDB的Buffer Pool为例，虽然它是一块预先申请的大内存区域，但其内部是由无数个16KB的页（对应多个4KB系统页）组成的，这些页随着数据的读写在Buffer Pool中被频繁地换入换出、分配和释放。PostgreSQL的共享缓冲区也是类似的情况。这种模式导致物理内存中很难长期维持大片的、连续的4KB页，而这正是THP能够成功合并的前提。

其次，数据库对延迟的稳定性极为敏感。一次查询响应时间从1毫秒跳到100毫秒，对用户体验和系统监控来说就是一次严重的事故。而THP的自动合并机制，正是这种“毛刺”的潜在制造者。

罪魁祸首：khugepaged 与直接回收风暴

THP的自动合并主要由一个叫做 khugepaged 的内核守护进程（线程）来完成。它会周期性地扫描进程的匿名内存（比如InnoDB Buffer Pool），尝试将符合条件的连续小页合并成大页。

这里就产生了第一个问题：锁竞争与CPU开销。当 khugepaged 尝试合并一片内存区域时，它需要对这片区域“上锁”，以防止应用程序同时进行内存访问。对于数据库这种每时每刻都在进行内存操作的高频进程，这种锁竞争会直接导致应用程序在申请或访问内存时发生短暂的停顿。你可能在监控图上看到的就是周期性的、难以解释的查询延迟尖峰。

更严重的情况是“直接回收”（Direct Reclaim）。设想一个场景：数据库正在运行，内存已经比较碎片化了。此时，某个操作需要分配一块2MB的透明大页（可能是因为THP策略被触发）。内核发现当前没有现成的、连续的512个小页可用，但它“决心”要满足这个分配请求。

于是，内核会启动一个非常激进的同步内存回收和压缩过程。它会尝试立刻整理出连续的物理内存，这个过程可能会阻塞当前请求的进程，直到回收完成。对于数据库来说，这就好比在一条繁忙的高速公路上突然为了修一个路口，让所有车辆完全停下来等待。导致的后果就是整个数据库线程的短暂“卡死”，表现为秒级的服务不可用或超时。这在早期的内核版本（如3.0）中尤为严重，虽然后续版本有所改善，但在高内存压力下，这个风险依然存在。

性能对比：理想与现实的差距

为了更直观地理解THP在不同场景下的影响，可以参考下面的对比：

另一个隐藏问题：内存浪费与NUMA困境

除了延迟，THP还可能造成内存使用过量。因为THP的合并单位是2MB，即使一个数据库进程只使用了其中某一个2MB大页里的几个字节，整个2MB页都会被算作该进程的常驻内存（RSS）。这可能导致监控显示的内存使用率远高于实际需求，误导容量规划。

在NUMA（非统一内存访问）架构的服务器上，问题会更复杂。THP可能会无意中导致内存页被分配在非本地（remote）的NUMA节点上。原本按4KB小页分配可以很好地分布在各个节点，保持访问本地性。但合并成一个2MB大页时，这个页只能位于某一个节点。如果访问这个页的进程跑在另一个节点的CPU上，就会产生大量的远程内存访问，带来额外的延迟。这种性能损失通常在3%-5%甚至更高，取决于跨节点访问的代价。

你可以通过以下命令检查THP活动情况，如果看到AnonHugePages有数值，说明THP正在工作：

cat /proc/meminfo | grep -i huge
AnonHugePages:    122880 kB
HugePages_Total:       0
HugePages_Free:        0
...

实践建议：关闭、验证与替代方案

对于数据库服务器，最稳妥的做法是全局关闭THP。

如何正确关闭THP

临时关闭（立即生效）：

echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

永久关闭（推荐）： 对于使用systemd的系统，创建一个服务单元文件是最可靠的方式，能确保在数据库服务启动前就禁用THP。

创建文件 /etc/systemd/system/disable-thp.service：

[Unit]
Description=Disable Transparent Huge Pages (THP)
After=sysinit.target local-fs.target
Before=mysql.service postgresql.service mongod.service # 根据你的数据库服务名调整

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'echo never | tee /sys/kernel/mm/transparent_hugepage/enabled > /dev/null'
ExecStart=/bin/sh -c 'echo never | tee /sys/kernel/mm/transparent_hugepage/defrag > /dev/null'

[Install]
WantedBy=multi-user.target

然后启用并启动该服务：

systemctl daemon-reload
systemctl enable --now disable-thp.service

验证： 检查以下文件内容，确保输出中包含 [never]。

cat /sys/kernel/mm/transparent_hugepage/enabled
cat /sys/kernel/mm/transparent_hugepage/defrag

同时，确认 /proc/meminfo 中的 AnonHugePages 项为0或保持极低且不再增长。

如果实在不能全局关闭？

在某些环境中，可能其他应用依赖THP。这时可以考虑仅对数据库进程进行优化：

• 使用替代的内存分配器：为数据库进程配置jemalloc或tcmalloc，并在编译时或运行时禁用其内部的THP支持（例如jemalloc的MALLOC_CONF="thp:never"）。
• 考虑显式大页（Explicit HugePages）：如果数据库确实存在TLB压力（需要通过性能剖析工具确认），可以配置静态的显式大页。这需要预先计算并预留固定数量的大页，数据库启动时显式申请使用。这避免了动态合并的副作用，但配置更复杂，且缺乏灵活性。MySQL、Oracle等数据库支持此特性。

总结

关闭透明大页，不是一个盲从的“玄学”配置，而是基于数据库特定负载模式与Linux内核机制交互的深刻理解后做出的工程决策。THP的“透明”和“自动”特性，在面对数据库高频、随机、碎片化的内存访问，以及对延迟稳定性的严苛要求时，其后台合并机制带来的锁竞争、CPU开销和不可预测的直接回收风险，远远超过了其可能带来的TLB性能收益。

因此，对于任何追求稳定低延迟的在线数据服务，将echo never > /sys/kernel/mm/transparent_hugepage/enabled写入启动脚本，应该成为服务器初始化清单中必不可少的一步。这关闭的不仅是一个内核特性，更是关掉了一个潜在的性能抖动源，为数据库的平稳运行扫清了一个重要的障碍。