首页 文章

通过-Xmx分配更多内存时，Sun JVM是否会变慢？

提问于
浏览 次
8

当更多内存可用并通过-Xmx使用时，Sun JVM是否会变慢？ （假设：机器有足够的物理内存，因此虚拟内存交换不是问题 . ）

我问，因为我的 生产环境 服务器将接收内存升级 . 我想把-Xmx值提升到颓废的东西 . 我们的想法是防止由于我自己不时发生的编程错误导致的任何堆空间耗尽失败 . 罕见的事件，但如果我有一个淫秽的-Xmx值，如2048mb或更高，我可以通过快速发展的webapp避免它们 . 应用程序受到严密监控，因此会注意到JVM内存消耗的异常峰值并修复任何缺陷 .

可能的重要细节：

  • Java 6（在64位模式下运行）

  • 4核Xeon

  • RHEL4 64位

  • Spring，Hibernate

  • 高磁盘和网络IO

EDIT ：我试图避免发布我的JVM的配置，但很明显这使得这个问题荒谬地开放 . 所以，这里我们使用相关的配置参数：

-Xms256m 
-Xmx1024m 
-XX:+UseConcMarkSweepGC 
-XX:+AlwaysActAsServerClassMachine 
-XX:MaxGCPauseMillis=1000 
-XX:MaxGCMinorPauseMillis=1000 
-XX:+PrintGCTimeStamps 
-XX:+HeapDumpOnOutOfMemoryError
java jvm performance

5 回答

  • 0

    通过添加更多内存，堆填满需要更长时间 . 因此，它将减少垃圾收集的频率 . 但是，根据您的物体的致命程度，您可能会发现任何单个GC增加所需的时间 .

    GC需要多长时间的主要因素是有多少活动对象 . 因此，如果几乎所有的物体都很年轻，一旦你 Build 起来，它们都没有逃过年轻的堆，你可能不会注意到GC的运行时间变化很大 . 但是，每当你必须循环使用tenured heap时，你可能会发现一切都停止了不合理的时间，因为大多数这些对象仍然存在 . 相应地调整大小 .

    回复于
  • 0

    如果您只是为问题投入更多内存，那么您的应用程序中的吞吐量会更高，但如果您不在使用CMS垃圾收集器的多核系统上，则响应速度会下降 . 这是因为会发生更少的GC，但他们还有更多的工作要做 . 好处是你可以通过你的GC释放更多的内存，因此分配将继续非常便宜，因此更高的吞吐量 .

    顺便说一句，你似乎让-Xmx和-Xms感到困惑 . -Xms只设置初始堆大小，而-Xmx是最大堆大小 .

    回复于
  • 6

    更多内存通常可以在垃圾收集环境中提供更好的性能，至少只要这不会导致虚拟内存使用/交换 .

    GC仅跟踪引用，而不是内存本身 . 最后，VM将分配相同数量的（大多数是短暂的，临时的）对象，但垃圾收集器需要不经常调用 - 因此垃圾收集器工作的总量将不会更多 - 甚至更少，因为这也可以帮助使用弱引用的缓存机制 .

    我不确定是否还有64位服务器和客户端虚拟机（有32位），所以你可能也想调查一下 .

    回复于
  • 4

    根据我的经验，它并没有减速但是JVM一直试图削减到Xms并试图保持在较低的边界或接近 . 因此，如果你可以努力，也可以碰撞Xms . Sun推荐两款相同的尺寸 . 添加一些-XX：NewSize = 512m（只是一个编号），以避免老一代中昂贵的旧数据堆积，导致路上更长/更重的GC . 我们使用700 MB NewSize运行我们的Web应用程序，因为大多数数据都是短暂的 .

    所以，底线：我不希望减速，但让你更多的记忆力 . 设置一个更大的新尺寸区域并将Xms设置为Xmx以降低GC上的压力，因为它不需要尝试减少到Xms限制...

    回复于
  • 0

    如果增加-Xmx，它通常无法帮助您提高性能/吞吐量 . 从理论上讲，可能会有更长的“停止世界”阶段，但在实践中，CMS并不是一个真正的问题 .

    当然你不应该把-Xmx设置为像300Gbyte这样的疯狂值，除非你真的需要它:)

    回复于

相关问题