迁移到64位JVM的经验

我们公司正计划迁移到64位JVM，以摆脱2 GB最大堆大小限制。谷歌给了我很多有关64位JVM性能的结果。有没有人尝试迁移到64位Java和分享您的经验迁移到64位JVM的经验

2010-03-31 Fazal

x64或非x64？大多数情况下，它只会增加内存使用量并因此增加内存带宽。对于x86来说，AMD创造的指令集比x86要少。 – 2010-03-31 14:55:55

@安德斯，不是每个人都像你一样痴迷于这些数字！：P有些人（你能想象吗？）答案只是为了帮助。 – 2010-03-31 14:58:29

@Vladimir Dyuzhev：痴迷不是问题。这是社区工作的方式。回答和接受是如何确定谁有良好答案的历史。没有接受意味着没有好的答案的历史。没有良好答案的历史，很难知道有多少信任投入答案。 – 2010-03-31 15:05:19

如果您需要更大的堆，那么性能的问题是相当实际意义，不是吗？或者你有计划进行水平缩放吗？

，我已经与64位应用程序听到的主要问题是，一个完整的垃圾收集可能需要很长的时间（因为它是基于活动对象的数量）。所以你要仔细调整GC参数以避免完整的收集（我听说过一个有64 Gb堆的公司的轶事，并调整了他们的GC，以便他们永远不会完整的GC;他们只会关闭每周下降一次）。

除此之外，认识到Java是32位设计，所以你可能不会看到在同一时间将数据移动64位的任何巨大的性能提升。而你仍然只限于32位数组索引。

来源

2010-03-31 14:56:01 Anon

我们有一个JVM，其中并行运行的gc运行良好，但如果在下一个gc要启动时未完成gc，则JVM会暂停，直到完成第二个gc。坏！由于操作系统非常积极地将内存交换出去，因此会稍微有些变化。 – 2010-03-31 18:42:08

你能解释一下你的意思是Java是32位的设计吗？据我所知，Java是独立于设计平台的平台？ – Pacerier 2011-11-24 04:49:03

关于32位设计的评论很奇怪。当我们讨论32/64/128位时，它通常与指针的大小有关，这会影响工作内存的大小。 Java使用数组ints来限制单个数组的大小，但像nio缓冲区这样的抽象可以用来有效解决这个问题。由于这并不完美，因此有计划允许指数多头。但是，这不是像4Gb的最大堆那样的技术方面的限制。 – 2012-10-15 07:38:16

我们直接写入64位，我看不出有任何的不良行为......

来源

2010-03-31 14:40:58 Yaneeve

工作正常的我们。你为什么不简单地尝试设置它，并在像jvisualvm这样的profiler下运行你的负载测试套件？

来源

2010-03-31 14:44:53

一言以蔽之： 64位JVM会消耗对象引用和一些其他类型的内存（一般不显著），消耗每个线程（通常在高容量网站显著）更多的内存，使您能够有较大的堆（一般只如果你有很多长寿的对象很重要）

更长的答案/评论：

的评论说，Java是32位乘设计是一种误导。 Java 存储器寻址是64位的32或者，但VM规范确保大多数字段（例如int，long，double，等）都是相同的，无论如何。
而且 - GC的调整意见，同时相关的对象的数量，可能是不相关的，GC可以快速上 JVM上有大堆（我工作与堆高达15GB，非常快速GC） - 它更多地取决于你如何与代收集计划玩的，你的对象使用模式。虽然在过去人已经花了很多精力调整参数，这是非常工作量依赖，而现代（在Java 5+）的JVM 是在自我调整非常好 - 除非你有大量的数据你更可能会损害你自己，而不是帮助进行攻击性JVM调优。
由于在x86架构上提到， 64位EMT64或x64处理器还包括像原子写入做的事情，或者其他选项也可能影响高性能应用的新指令。

来源

2010-03-31 23:32:05 jayshao

你能解释一下“字段（例如int，long，double等）是什么意思吗？ – Pacerier 2011-11-24 04:50:24

天真地采取32位JVM工作负载并把它们放在64位产生一个性能和空间打击我的经验。但是，大多数主要的JVM供应商现在已经实现了一种基本上压缩一些堆的良好技术 - 它被称为压缩引用或压缩oops，用于不是“大”的64位JVM（即：在4 -30gb范围）。

这产生了很大的差异，应该使32-> 64的转换影响更小。

参考IBM JVM：link text

来源

2010-04-14 21:45:17

我认为这是-XX：+ UseCompressedOops for oracle jvm – Karussell 2011-02-21 19:46:18

迁移到64位JVM的经验

回答

相关问题