2

我们注意到垃圾收集期间 JVM 的大量暂停，其中用户和系统时间远小于总时间。[Times: user=3.99 sys=0.55, real=34.29 secs] 我们怀疑这可能是由于内存管理和检查透明和大页面配置显示两者都被禁用：

/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 位。谢谢！

4

1 回答 1

1

要真正摆脱 THP，您必须确保不仅禁用了 THP 守护程序，而且还禁用了 THP 碎片整理工具。defrag 将独立于 THP 运行，而 中的设置/sys/kernel/mm/khugepaged/defrag仅允许控制 THP 守护程序是否也可以运行 defrag。这意味着：即使您的应用程序没有获得 THP 的（潜在）好处，使您的系统停止的碎片整理过程仍然有效。

鼓励使用独立于发行版的路径来控制 THP 和碎片整理设置：/sys/kernel/mm/transparent_hugepage/（可能是 /sys/kernel/mm/redhat_transparent_hugepage 的符号链接）

这导致：

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

如果您正在运行 java 应用程序并想知道 THP/defrag 是否导致 jvm 暂停或停止，则可能值得查看您的 gc 日志。启用 -XX:+PrintGcDetails 后，您可能会观察到比系统/用户时间长得多的“真实”时间。

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

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

最早对 THP 的负面影响的描述是 Greg Rahn 的这篇博文：http: //structureddata.org/2012/06/18/linux-6-transparent-huge-pages-and-hadoop-workloads/

于 2015-12-21T09:52:12.227 回答