Java 在64位Linux服务器上运行64位JVM的优点/缺点？

我们在64位Linux 2.6服务器上运行32位Sun Java 5 JVM，但显然这将每个进程的最大内存限制为2GB。因此，有人建议我们升级到64位JVM以消除限制。我们目前在一台服务器上运行多个JVM（Tomcat实例），以保持2GB的限制，但为了简化部署，我们希望整合它们

如果你已经这样做了，你能分享你的经验吗？您是否在生产中运行64位JVM？您是建议继续使用Java5，还是可以同时使用Java6和64位？我们是否应该预期性能问题，是更好还是更糟？回归测试有哪些特别的方面值得我们关注

谢谢你的提示

在科学运营中心，我们有大约50台机器，每台32-64克。JVM堆通常为7-20G。我们正在使用Java6。该操作系统具有Linux 2.6内核

当我们迁移到64位时，我预计运行64位JVM会有一些问题，但实际上并没有。内存不足的情况更难调试，因为堆转储要大得多。需要进行一些修改以支持更大的堆大小

---

网络上有一些网站声称GC的扩展速度远远超过2G，但我没有看到任何问题。最后，我们正在进行吞吐量密集型而非交互式密集型计算。我从来没有考虑过延迟差异；我猜最坏的情况是，堆大小越大，GC延迟越长。

我们使用64位JVM，堆大小大约为40Gb。在我们的应用程序中，缓存了大量数据，从而产生了大量“旧”代。默认的垃圾收集设置不能很好地工作，需要在生产中进行一些痛苦的调整。教训：在像这样扩展之前，确保您有足够的负载测试基础设施。也就是说，一旦我们解决了问题，GC的性能就非常好。

我可以证实Sean的经验。我们运行的是纯Java、计算密集型web服务（家常的Jetty集成，现在有超过1k的servlet线程，内存中加载的数据超过6Gb），我们所有的应用程序在两年前迁移时都可以很好地扩展到64位JVM。我建议使用最新的sunjvm，因为在过去的几个版本中，GC开销已经有了实质性的改进。我对Tanukisoftware的包装器也没有任何问题。

您编写的任何假定它以32位运行的JNI代码都需要重新测试。有关将c代码从32位移植到64位时可能遇到的问题，请参阅此链接。它不是特定于JNI的，但仍然适用

如果使用numactl——显示您可以看到服务器中内存库的大小。

---

我发现GC在使用多个内存库时无法很好地扩展。这与其说是软件问题，不如说是硬件问题，但它同样会影响GC时间。

从JDK5 32位（Windows服务器）迁移到JDK6 64位后，“perm gen space”内存块出现泄漏。在使用JDK参数后，问题得到解决。希望你能比我们更幸运。

我很久以前在Tanukisoftware的包装上做了这个改动。他们的网页似乎表明他们现在有64位二进制文件可供下载。也许我会更新到最新版本。谢谢此外，它不需要重新编译吗？如果您有结果或意见要分享，我想听听您关于垃圾收集器调优的更多发现？这是Sun JVM？您好，我想了解更多关于您为解决永久空间问题而调整的参数的信息。我有一个应用程序，在32位Windows中运行良好，但在RedHat 64位中内存不足。非常感谢。