我正在寻找适当的设置来为 Web应用程序配置JVM。我已经阅读了有关旧/年/ perm生成的内容,但我最好在这种配置中使用这些参数。
在4 GB中, 3 GB左右用于缓存(使用EhCache的应用缓存),所以我正在寻找最佳设置。仅供参考,缓存在应用程序的生命周期内是静态的(从磁盘加载,永不过期),但使用频繁。
我已经分析了我的应用程序,并且我已经对数据库查询,应用程序的体系结构,缓存大小等进行了优化...... 我只是在寻找JVM配置建议此处即可。我已经测量了垃圾收集器的 99%吞吐量,并且当Full GC运行时(大约每1 / 2h一次) 6-8s暂停。
以下是当前的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个核心。
答案 0 :(得分:5)
-XX:+ UseParallel * 旧 * GC应该可以加速多核计算机上的Full GC。
您还可以使用不同的NewRatio值进行分析。您的缓存对象将存在于tenured generation中,因此使用-XX:NewRatio = 7对其进行分析,然后再使用一些更高和更低的值进行分析。
您可能无法在分析过程中准确复制实际使用,因此请确保在实际使用中监控GC,然后您可以进行微小更改(例如幸存者空间等)并查看它们具有什么效果。
老建议不要将AggressiveHeap与Xms和Xmx一起使用,我不确定是否仍然如此。
编辑:请告诉我们您部署的操作系统/硬件平台。
每30分钟收集一次,表明老一代人已经满员。 newRatio的高价值将为年轻人带来更多空间。你能给JVM超过4克还是仅限于此?
知道您的目标/非功能要求是什么也很有用。您是否希望避免这些6/7秒暂停,从而降低吞吐量的风险,或者是否为可能的最高吞吐量暂停可接受的折衷?
如果要最小化暂停,请通过删除
来尝试CMS收集器-XX:+UseParallelGC -XX:+UseParallelOldGC
并添加
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC
使用各种NewRatio值的配置文件,看看你如何继续。
CMS收集器的一个缺点是,与并行旧的和串行收集器不同,它不会压缩老一代。如果旧一代变得过于分散,并且次要集合需要同时向旧gen发起大量对象,则可能会调用完整的序列集合,这可能意味着长时间停顿。 (我曾经在prod中看到过这种情况,但IBM JVM内存不足而不是调用压缩集合!)
这对您来说可能不是问题 - 这取决于应用程序的性质 - 但您可以通过每晚或每周重新启动来保证它。
答案 1 :(得分:4)
我会使用Java 6更新30或7更新2,64位,因为它们更有效。例如它们默认使用32位引用。
如果可能,我还会将Ehcache配置为使用直接内存或内存映射文件。这应该最小化对GC的影响。
使用这些选项可以几乎消除堆脚印。例如我有一个应用程序,在具有16 GB内存的计算机上使用高达180 GB的内存映射文件,堆大小为6 MB。手动触发时,完整GC最多需要11 ms,而不是GC。 ;)
如果你想要一个简单的例子,我将8 TB文件映射到内存并更新它。 http://vanillajava.blogspot.com/2011/12/using-memory-mapped-file-for-huge.html
答案 2 :(得分:0)
我希望您刚删除-server以不对帖子进行充气,否则您应该立即启用它。除了更长的启动时间(对于应该运行几天的Web应用程序来说,这确实不是问题)我没有看到任何理由除了使用c2之外的任何东西。总的来说,这可以带来一些不错的性能提升。 Umn回到主题:
可悲的是,我能想到的最好的事情不适用于您的古老JVM。 G1垃圾收集器基本上是为减少延迟而设计的。它不仅试图减少暂停,还提供一些调整参数来设置暂停目标和间隔。见this page。
虽然我怀疑它是不断更新的,但是有一个实验性的回溯到java6。没有人在浪费任何时间来优化GC或其他任何我为Java 1.5做的事情了。
PS:还有IBM的JVM,显然azul systems(确定这不是一个严肃的命题;)),但这些显然是不可能的......只是想提一下。