Memory management 透明巨大页面已禁用，但压缩暂停不为空

我们注意到，在垃圾收集过程中，JVM会出现较大的暂停，其中用户和系统时间远远小于总时间。[Times:user=3.99 sys=0.55，real=34.29秒]我们怀疑这可能是由于内存管理，并检查了透明和巨大页面配置，显示这两个页面都被禁用：

/sys/kernel/mm/redhat_transparent_hugepage/enabled:always [never]
/sys/kernel/mm/redhat_transparent_hugepage/defrag:[always] never
/sys/kernel/mm/redhat_transparent_hugepage/khugepaged/defrag:[yes] no

然而，从THP和相关计数器来看，我们看到许多压缩暂停： egrep‘trans | thp | compact |’/proc/vmstat

nr_anon_transparent_hugepages 0 
compact_blocks_moved 113682 
compact_pages_moved 3535156 
compact_pagemigrate_failed 0 
compact_stall 1944 
compact_fail 186 
compact_success 1758 
thp_fault_alloc 6 
thp_fault_fallback 0 
thp_collapse_alloc 15 
thp_collapse_alloc_failed 0 
thp_split 17

所以问题是，如果禁用THP，为什么THP和压缩暂停/失败计数器不为0，以及如何禁用压缩以使其不干扰JVM（我们认为这是GC长时间暂停的原因）

---

这发生在RHEL6.2、2.6.32-279.5.2.el6.x86_64、JVM 6u21 32位上。谢谢

要真正摆脱THP，您必须确保不仅禁用THP守护进程，而且禁用THP碎片整理工具。碎片整理将独立于THP运行，而

/sys/kernel/mm/khugepaged/defrag

中的设置仅允许控制THP后台程序是否也可以运行碎片整理。 这意味着：即使您的应用程序没有获得THP的（潜在）好处，使系统暂停的碎片整理过程仍然处于活动状态

建议使用独立于分发的路径来控制THP和碎片整理设置： /sys/kernel/mm/transparent\u hugepage/（可能是/sys/kernel/mm/redhat\u transparent\u hugepage的符号链接）

这导致：

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

如果您正在运行一个java应用程序，并且想知道THP/defrag是否导致jvm暂停或暂停，那么有必要查看一下您的gc日志。启用-XX:+PrintGcDetails后，您可能会观察到比sys/user时间长得多的“真实”时间

在我的情况下，以下一行就足够了

less gc.log | grep sys=0 | grep user=0 | grep -P "real=[1-9]"

---

关于THP负面影响的最早描述是Greg Rahn的这篇博文：

这“/sys/kernel/mm/redhat\u transparent\u hugepage/defrag:[始终]从不”是否意味着它已启用？“总是[从来没有]”不是指禁用吗？我想我在Centos上也有类似的问题，是否关闭了透明的大页面工作？我发现有趣的是，我读到的大多数关于THP的帖子都没有提到这一点（我们自己也肯定看到过），但人们注意到仅仅禁用THP就足以解决他们的问题（包括各种数据存储的文档）。我想知道禁用是否足以解决由于THP引起的大部分延迟问题，而这只是完全清除了它？正如我已经说过的：内存碎片整理（导致系统暂停）由THP守护程序和碎片整理守护程序启动。禁用THP可能会减少暂停次数。在某些情况下，这就足够了，但谁真的想用“可能”来停止呢？是的。有趣的是，我们还发现，我们仍然看到暂停的延迟问题（在/proc/vmstat中，compact_stall的值仍在上升）尽管我们已经禁用了THP（在引导期间作为内核参数）和碎片整理（在运行时），但这个问题远没有以前那么严重。我们正在继续调查它。compact_stall计数器也报告了kswapd活动。