7

我正在寻找适当的设置来为Web 应用程序配置 JVM 。我已经阅读了有关旧/新/烫发一代的信息，但我无法在最好的情况下使用这些参数来进行此配置。

在 4 GB 中，大约3 GB 用于缓存（使用EhCache的应用缓存），因此我正在寻找考虑到这一点的最佳设置。仅供参考，缓存在应用程序的生命周期内是静态的（从磁盘加载，永不过期），但被大量使用。

我已经分析了我的应用程序，并且我已经对数据库查询、应用程序的架构、缓存大小等进行了优化......我只是在这里寻找 JVM 配置建议。我测量了垃圾收集器的99% 吞吐量，并且在 Full GC 运行时暂停 6-8 秒（大约每 1/2 小时一次）。

以下是当前的 JVM 参数：

-XX:+UseParallelGC -XX:+AggressiveHeap -Xms2048m -Xmx4096m
-XX:NewSize=64m -XX:PermSize=64m -XX:MaxPermSize=512m
-verbose:gc -XX:+PrintGCDetails -Xloggc:gc.log

那些参数可能完全关闭了，因为它们是很久以前写的......在应用程序变得那么大之前。

我正在使用 Java 1.5 64 位。

您看到任何可能的改进吗？

编辑：机器有4个核心。

4

3 回答 3

5

-XX:+UseParallel* Old *GC 应该加速多核机器上的 Full GC。

您还可以使用不同的 NewRatio 值进行概要分析。您的缓存对象将存在于终身代中，因此使用 -XX:NewRatio=7 对其进行分析，然后再次使用一些更高和更低的值。

您可能无法在分析期间准确地复制实际使用情况，因此请确保在实际使用时监控 GC，然后您可以进行微小的更改（例如，对幸存者空间等）并查看它们有什么影响。

旧的建议是不要将 AggressiveHeap 与 Xms 和 Xmx 一起使用，我不确定这是否仍然正确。

编辑：请让我们知道您部署在哪个操作系统/硬件平台上。

每 30 分钟一次完整的收集表明老年代已经很满了。newRatio 的高值会以牺牲年轻一代为代价为其提供更多空间。你能给 JVM 超过 4g 还是仅限于此？

了解您的目标/非功能性要求也是有用的。您是否要冒着降低吞吐量的风险避免这些 6 / 7 秒的停顿，或者这些停顿是为了获得尽可能高的吞吐量而可接受的折衷方案？

如果您想最小化暂停，请尝试 CMS 收集器，将两者都删除

-XX:+UseParallelGC -XX:+UseParallelOldGC

并添加

-XX:+UseConcMarkSweepGC -XX:+UseParNewGC

使用各种 NewRatio 值对其进行概要分析，看看你的进展情况。

CMS 收集器的一个缺点是，与并行的老年代和串行收集器不同，它不会压缩老年代。如果老年代太碎片化并且次要集合需要一次将大量对象提升到老年代，则可能会调用完整的串行集合，这可能意味着长时间的停顿。（我曾经在 prod 中看到过这种情况，但是 IBM JVM 内存不足而不是调用压缩集合！）

这对您来说可能不是问题 - 这取决于应用程序的性质 - 但您可以通过每晚或每周重新启动来确保它不会受到影响。

于 2012-01-10T13:30:37.623 回答
4

我会使用 Java 6 update 30 或 7 update 2、64 位，因为它们效率更高。例如，他们默认使用 32 位引用。

如果可能，我还将配置 Ehcache 以使用直接内存或内存映射文件。这应该尽量减少对 GC 的影响。

使用这些选项几乎可以消除您的堆足迹。例如，我有一个应用程序，它在具有 16 GB 内存且堆大小为 6 MB 的机器上使用多达 180 GB 的内存映射文件。手动触发时，完整的 GC 最多需要 11 毫秒，而不是 GC。;)

如果你想要一个简单的例子，我将一个 8 TB 的文件映射到内存中并更新它。http://vanillajava.blogspot.com/2011/12/using-memory-mapped-file-for-huge.html

于 2012-01-10T13:30:54.580 回答
0

我希望您刚刚删除 -server 以不夸大帖子，否则您应该立即启用它。除了更长的启动时间（这对于应该运行数天的 Web 应用程序来说确实不是问题），我认为除了 c2 之外没有任何理由使用任何东西。一般来说，这可以带来一些不错的性能改进。嗯 回到主题：

遗憾的是，我能想到的最好的东西不适用于您古老的 JVM。G1 垃圾收集器基本上是为了减少延迟而设计的。它不仅尝试总体上减少暂停，还提供一些调整参数来设置暂停目标和间隔。请参阅此页面。

java6 有一个实验性的反向移植，但我怀疑它是否保持最新。我担心没有人会再浪费时间优化 Java 1.5 的 GC 或其他任何东西了。

PS：还有 IBM 的 JVM 和显然azul 系统（好吧，这不是一个严肃的提议；）），但这些显然是不可能的……只是想提一下。

于 2012-01-10T17:45:42.023 回答