Linux系统调优：针对Doris BE服务器关闭透明大页（THP）-CFANZ编程社区

Doris（以及大多数其他大数据组件，如Redis、MongoDB、Cassandra等）建议关闭Linux的透明大页（Transparent HugePages, THP），主要是出于性能稳定性和可预测的延迟的考虑，而不是为了绝对的内存吞吐量。

下面我将详细解释原因。

传统大页（Static HugePages）: 需要系统管理员预先分配好固定数量的大内存页，应用程序需要显式地请求使用它们。管理起来比较麻烦，但性能稳定。
透明大页（THP）: 是Linux内核的一个特性（从RHEL 6等开始引入），旨在自动管理大页，无需管理员干预和应用程序的修改。内核的 khugepaged 守护进程会在后台自动将常规的4KB小页合并为2MB甚至1GB的大页。

初衷是好的：减少页表项（TLB Miss）的数量，提高内存访问效率（特别是对于需要大量内存的应用程序）。

THP的设计理念与Doris这类需要长时间稳定运行、对延迟敏感的系统的工作模式存在根本性的冲突。核心问题在于其“透明”和“自动”的合并机制。

这个后台进程是导致问题的核心。它会不断地扫描内存，尝试将符合条件的小页合并成大页。这个合并过程本身是需要消耗系统资源的，并且会引入不确定性。

具体危害如下：

CPU 开销： khugepaged 在运行时，会消耗CPU资源。对于Doris这种期望CPU全力处理查询任务的系统来说，这是一个不受控制的“噪音邻居”。
内存锁竞争：在合并页面的过程中，内核需要对涉及的内存区域进行加锁。这可能会导致应用程序（如Doris的BE进程）在申请内存时发生短暂的停顿，从而引发查询延迟的尖峰。对于需要稳定低延迟的在线分析处理（OLAP）系统，这种毫秒级甚至秒级的停顿是完全不可接受的。

为了形成一个2MB的连续大页，内核需要找到512个连续的、物理地址相邻的4KB小页。在Doris这种长期运行、内存不断分配和释放的系统里，内存很容易变得碎片化。
当内存碎片化严重时，khugepaged 可能无法找到足够的连续小页来合并。此时，如果应用程序需要分配大页，它会触发一个直接压缩回收 机制。这个过程非常激进，会尝试同步地整理内存、回收页面，相当于一次“小型的、不可控的内存压力风暴”，直接导致系统性能急剧下降，甚至引起服务超时。

THP可能会过度积极地分配大页。例如，一个进程可能只使用了2MB大页中的1KB数据，但整个2MB都会被算作它的常驻内存（RSS）。这会导致内存使用率高于实际需求，可能挤占其他进程或操作系统的缓存。

对于Doris运维人员来说，THP是一个“黑盒”。它的行为由内核控制，难以精确监控和干预。当出现性能问题时，排查THP的影响非常困难。相比之下，关闭THP后，内存管理行为更加简单、可预测，便于进行问题诊断和性能分析。

大量内存操作： Doris BE在数据导入、 compaction（ compaction）和复杂查询（如Hash Join、排序、聚合）时，会频繁地分配和释放大量内存。
对延迟敏感：作为OLAP引擎，查询响应时间（P99延迟）是至关重要的服务指标。
长时间运行：服务需要7x24小时稳定运行，任何微小的、周期性的性能抖动累积起来都会影响整体服务体验。

THP的“自动化优化”恰恰与这些特性相悖，它带来的微小性能收益远不足以抵消其引入的性能不确定性和风险。

操作命令：

关闭THP通常是一个系统级操作，需要root权限。

cat /sys/kernel/mm/transparent_hugepage/enabled

输出示例：[always] madvise never。如果 always 被括号括起来，表示THP处于全局启用模式。

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

修改GRUB配置，在 /etc/default/grub 中的 GRUB_CMDLINE_LINUX 行添加 transparent_hugepage=never。
更新GRUB并重启系统。
或者，也可以将其添加到 /etc/rc.local 中，确保开机执行。

结论：

Doris建议关闭透明大页，根本目的是为了消除一个由内核自动管理机制引入的、不可预测的性能干扰源，以换取更稳定、更可预测的查询延迟，从而保障服务的整体稳定性。这是在生产环境中经过大量实践验证的有效优化手段。