我是Java的新手，并且刚刚继承了Tomcat设置，所以我想要一些指导:)我在上周阅读了有关JVM调优和垃圾收集算法的更多信息，而不是我想要的！
使用Visual VM / GC，我们的Tomcat服务器每天只能完成一次GC。鉴于大多数用户的网络会话持续时间不到一小时，这对于mee来说似乎很少见，并且可能很长时间内烫发器中存在很多“死”对象？那么这只是意味着我们有足够的RAM /堆空间，它根本不需要收集所以它不是吗？
考虑到这一点，由于促销率非常小，是否会让旧版本更小，新版本更大呢？
我问，因为操作系统的其他地方有迹象表明我们可能会有内存压力，但JVM / GC日志似乎与操作系统相矛盾。
与此相关 -
我们目前有min-heap=max-heap=6Gb。如果top显示java进程大小为7-8Gb，但RSS为5-6Gb，可能这意味着2Gb被换出？在这种情况下，当它充满GC时它就会死掉。因此，在操作系统交换之前，更频繁地使用较小的最小堆大小会更好。
通常最好让JVM自行调整，而不是手动设置所有参数，或者大多数人手动设置参数吗？
答案 0 :(得分：8)
垃圾收集是内存分配和性能之间的权衡。想象你的阁楼。如果你继续扔东西，最终它会变满，你将不得不把它清理干净。如果你有一个小阁楼，你可能每月填一次，但它只需要20分钟来整理。如果你有一个非常大的阁楼，可能需要一年的时间来填补，但周末要清理。
JVM也是如此。如果你分配6 GB，但你真的可以通过1.5 GB，那么垃圾收集的频率会低得多，但是当它们发生时，它可能会让世界停止超过一分钟。
如果清除（从Eden复制到Survivor）正在恢复大部分内存，那么你有很多非常短暂的对象。如果增加新一代的大小，那么这些垃圾收集将变得不那么频繁，但是它们将花费更长的时间。理想情况下，您希望这些内容尽可能快，这意味着保持这个空间足够小以便可以快速扫描，但是足够大以至于短期对象不会被提升到终身代。 我不会修改新一代的大小，除非我确信短期（即请求）对象在他们不应该的时候被终身。
如果它现在花了几天时间来填充6 GB，假设堆积累了来自每个用户会话的对象并请求你自上次完整的GC 之后就已经拥有了，我' d怀疑你用完整的GC释放了大量的垃圾。如果你不是，那么你应该调查你是否有内存泄漏（可能是一个流氓缓存）。如果使用完整的GC释放大部分堆，则应该调查较小的堆大小是否有意义。
较小的堆将增加完整垃圾收集的频率，但会使停顿显着缩短。在一个Web应用程序中，如果它们在高峰期发生，那么完全垃圾收集的长期停留是不可接受的。
如果您正在指示Java堆可能被操作系统交换，那么您肯定应该考虑缩小它。但我不会篡改新一代的尺寸。
答案 1 :(得分：8)
您使用的是哪种版本的Tomcat？
内存泄漏预防gubbins中存在一个错误 一小时内完整的GC：
https://issues.apache.org/bugzilla/show_bug.cgi?id=53267
（注意bug在tomcat7上提到它，但是6也受影响，在6.0.36中修复）
答案 2 :(得分：2)
根据我的经验，我认为这些陈述
“服务器每天完成GC的次数减少”
和
“在操作系统的其他地方有迹象表明我们可能有记忆 压力“
彼此矛盾。通常情况下，GC的频率随着内存流失而增加，发生的频率越低越好。
请记住，完整的GC意味着所有应用程序活动都已停止 - 有时这可能需要几分钟，特别是对于大堆！
例如，在这里，我有许多实时运行的系统，每个系统有~1.4K的HTTP会话，每个框（-Xmx=13g）每小时约1-2个完整的GC 。理想情况下，我们希望它更不频繁，但由于应用程序的性质，我们不能。
您需要澄清您尝试解决的真正问题是什么，因为根据您提供的信息，我看不到任何需要调整的问题。