在 jboss 5.0.1GA 中一小时后性能下降和奇怪的 GC 行为答案

【问题标题】：performance drop and strange GC behaviour after one hour in jboss 5.0.1GA在 jboss 5.0.1GA 中一小时后性能下降和奇怪的 GC 行为
【发布时间】：2013-08-16 12:29:21
【问题描述】：

我们将我们的软件从 jboss 4.0.5GA 升级到 5.0.1GA，并注意到大约一小时（或在某些情况下为 90 分钟）后性能急剧下降。

同时，垃圾收集器日志显示次要垃圾收集时间从 0.01 秒跃升至约 1.5 秒，每次清除的堆数量从之前的约 400MB 减少到之后的约 300MB。（参见 GC 查看器图 1）

我们认为这些都是同一个根本原因的症状。

jvm 设置为：

-server -Xms2048m -Xmx2048m -XX:NewSize=384m -XX:MaxNewSize=384m 
-XX:SurvivorRatio=4 -XX:MinHeapFreeRatio=11 -XX:PermSize=80m -verbose:gc
-XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+DisableExplicitGC 
-Djava.awt.headless=TRUE -DUseSunHttpHandler=TRUE 
-Dsun.net.client.defaultConnectTimeout=25000 
-Dsun.net.client.defaultReadTimeout=50000 -Dfile.encoding=UTF-8 
-Dvzzv.log.dir=${ercorebatch.log.dir} -Xloggc:${ercorebatch.log.dir}/gc.log  
-Duser.language=it -Duser.region=IT -Duser.country=IT -DVFjavaWL=er.core.it

生产环境是 T5220 或 T2000 硬件，具有 32 位 SPARC，运行 Solaris 10 虚拟机。 jboss 5.0.1.GA, java 1.6.0_17

我们设置了一个测试环境，由 2 个相同的机器组成，运行相同的软件，但一个使用 jboss 4.0.5GA，一个使用 jboss 5.0.1.GA。它们是在配备 4 x 2.2GHz Intel Xeon CPU E5-4620 和 64GB RAM 的 HP ProLiant DL560 Gen8 上运行的 VMWare VM。来宾虚拟机是 4 个 vCPU、4096MB RAM、CentOS 6.4。

我们发现我们可以很容易地在我们的环境中重现该问题。在 4.0.5 上运行的机器运行良好，但在 jboss 5.0.1GA 上我们看到了同样奇怪的 GC 行为。由于我们没有与生产相同的负载量，因此无法在我们的环境中轻松测试性能。

我们不认为是内存泄漏，因为每次major GC之后，使用的堆大小都会恢复到原来的大小：

分析世界末日前后的堆转储，我们发现以下对象的数量不同：

org.jboss.virtual.plugins.context.file.FileSystemContext

在第一个小时内，大约有 8 个，在世界末日来袭后，我们看到 100 到 800 个。

除此之外，堆转储看起来非常相似，顶部对象是 java 或 jboss 对象（即没有应用程序类）

在我们的测试环境中设置-Djboss.vfs.forceVfsJar=true 解决了这个问题（即奇怪的 GC 行为消失了），但是在生产中应用时，奇怪的 GC 模式和性能问题仍然存在 - 尽管 GC 时间没有增加太多（到0.3 秒而不是 1.5 秒）。

在我们的测试环境中，我们随后在 jboss 5.1.0 中部署了相同的软件，并发现与 5.0.1 相同的行为。

因此，此时的结论是 jboss 5.x 在 60 / 90 分钟左右发生了一些事情，这对垃圾收集和性能都有影响。

更新：

我们尝试将 Web 服务堆栈升级到 jbossws-native-3.3.1，这解决了我们测试环境中的问题。但是，当部署到下一个测试环境（更接近生产环境）时，问题仍然存在（尽管有所减少）。

更新：

我们通过将 jboss.vfs.cache.TimedPolicyCaching.lifetime 设置为一个非常大的数字（相当于很多年）解决了这个问题。

这感觉像是解决 jboss 中的错误的方法。默认缓存生命周期为 30 分钟（参见 org.jboss.util.TimedCachePolicy），我们在 60 或 90 分钟后发现了问题。

VFS 缓存实现是 CombinedVFSCache，我认为它在下面使用了 TimedVFSCache。

似乎更好的解决方法是将缓存实现更改为永久缓存，但我们已经在这个问题上浪费了足够多的时间，我们的解决方法将不得不这样做。

【问题讨论】：

根据您的问题，我假设您已经看到this bug 会影响 5.0.1 和 5.1.0GA？你不能使用 5.1.2 有什么原因吗？看到线程转储“后启示录”以查看是否还有其他原因导致 prod 减速会很有趣。最初的原因可能有两个。
嗨，迈克，是的，我们看到了那个错误，这就是为什么我们尝试了 vfs jvm 选项，但它不起作用。我相信 5.1.2 不能免费用于商业用途，这意味着我们不能像使用 5.1.0 一样使用它

标签： performance memory jboss garbage-collection

【解决方案1】：

仅查看 Gc 图很难确定此问题的根本原因。那么当这种情况发生时，堆栈看起来如何呢？是否有任何过度活跃的线程？是否有任何讨厌的线程创建大量对象，迫使垃圾收集器像地狱一样工作以摆脱它们？我认为必须进行更多分析以确定问题的根本原因。

【讨论】：