Java 非常大的堆大小
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/214362/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Java very large heap sizes
提问by pdeva
Does anyone have experience with using very large heaps, 12 GB or higher in Java?
有没有人有在 Java 中使用 12 GB 或更大的非常大的堆的经验？
- Does the GC make the program unusable?
- What GC params do you use?
- Which JVM, Sun or BEA would be better suited for this?
- Which platform, Linux or Windows, performs better under such conditions?
- In the case of Windows is there any performance difference to be had between 64 bit Vista and XP under such high memory loads?
- GC 是否使程序无法使用？
- 你使用什么 GC 参数？
- 哪个 JVM、Sun 或 BEA 更适合于此？
- 在这种情况下，Linux 或 Windows 哪个平台表现更好？
- 在 Windows 的情况下，在如此高的内存负载下，64 位 Vista 和 XP 之间是否存在性能差异？
回答by Ichorus
We have an application that we allocate 12-16 Gb for but it really only reaches 8-10 during normal operation. We use the Sun JVM (tried IBMs and it was a bit of a disaster but that just might have been ignorance on our part...I have friends that swear by it--that work at IBM). As long as you give your app breathing room, the JVM can handle large heap sizes with not too much GC. Plenty of 'extra' memory is key.
Linux is almost always more stable than Windows and when it is not stable it is a hell of a lot easier to figure out why. Solaris is rock solid as well and you get DTrace too :)
With these kind of loads, why on earth would you be using Vista or XP? You are just asking for trouble.
We don't do anything fancy with the GC params. We do set the minimum allocation to be equal to the maximum so it is not constantly trying to resize but that is it.
我们有一个应用程序，我们为其分配了 12-16 Gb，但在正常操作期间它实际上只达到 8-10。我们使用 Sun JVM（尝试过 IBM，这有点灾难，但这可能是我们的无知......我有朋友发誓——在 IBM 工作）。只要您给应用程序喘息的空间，JVM 就可以处理大堆大小而不会产生过多的 GC。大量的“额外”内存是关键。
Linux 几乎总是比 Windows 更稳定，当它不稳定时，找出原因要容易得多。Solaris 也是坚如磐石的，您也可以使用 DTrace :) 有了这些负载，您到底为什么要使用 Vista 或 XP？你只是自找麻烦。我们不会对 GC 参数做任何花哨的事情。我们确实将最小分配设置为等于最大分配，因此它不会不断尝试调整大小，仅此而已。
回答by jlintz
I recommend also considering taking a heap dump and see where memory usage can be improved in your app and analyzing the dump in something such as Eclipse's MAT. There are a few articles on the MAT page on getting started in looking for memory leaks. You can use jmap to obtain the dump with something such as ...
我还建议考虑进行堆转储，看看在您的应用程序中内存使用情况可以改进的地方，并在诸如Eclipse 的 MAT 之类的东西中分析转储。MAT 页面上有几篇关于查找内存泄漏的入门文章。您可以使用 jmap 来获取转储，例如...
jmap -heap:format=b pid
回答by Milhous
回答by Chris de Vries
If you switch to 64-bit you will use more memory. Pointers become 8 bytes instead of 4. If you are creating lots of objects this can be noticeable seeing as every object is a reference (pointer).
如果切换到 64 位，将使用更多内存。指针变为 8 个字节而不是 4 个字节。如果您正在创建大量对象，这会很明显，因为每个对象都是一个引用（指针）。
I have recently allocated 15GB of memory in Java using the Sun 1.6 JVM with no problems. Though it is all only allocated once. Not much more memory is allocated or released after the initial amount. This was on a Linux but I imagine the Sun JVM will work just as well on 64-bit Windows.
我最近使用 Sun 1.6 JVM 在 Java 中分配了 15GB 内存，没有出现任何问题。虽然都只分配了一次。在初始数量之后不会分配或释放更多内存。这是在 Linux 上，但我想 Sun JVM 在 64 位 Windows 上也能正常工作。
回答by anjanb
sun has had an itanium 64-bit jvm for a while although itanium is not a popular destination. The solaris and linux 64-bit JVMs should be what you should be after.
Some questions
尽管 itanium 不是一个受欢迎的目的地，sun 已经有一段时间了 itanium 64 位 jvm。solaris 和 linux 64 位 JVM 应该是您所追求的。
一些问题
1) is your application stable ?
2) have you already tested the app in a 32 bit JVM ?
3) is it OK to run multiple JVMs on the same box ?
1) 您的应用程序稳定吗？
2) 您是否已经在 32 位 JVM 中测试过该应用程序？
3) 可以在同一个机器上运行多个 JVM 吗？
I would expect the 64-bit OS from windows to get stable in about a year or so but until then, solaris/linux might be better bet.
我希望 Windows 的 64 位操作系统在大约一年左右的时间内变得稳定，但在那之前，solaris/linux 可能是更好的选择。
回答by anjanb
an article from sun on java 6 can help you : http://java.sun.com/developer/technicalArticles/javase/troubleshoot/
来自 sun 关于 Java 6 的文章可以帮助您：http: //java.sun.com/developer/technicalArticles/javase/troubleshoot/
回答by kohlerm
12Gb should be no problem with a decent JVM implementation such as Sun's Hotspot. I would advice you to use the Concurrent Mark and Sweep colllector ( -XX:+UseConcMarkSweepGC) when using a SUN VM.Otherwies you may face long "stop the world" phases, were all threads are stopped during a GC.
对于像 Sun 的 Hotspot 这样的体面的 JVM 实现，12Gb 应该没有问题。我建议您在使用 SUN VM 时使用并发标记和扫描收集器 (-XX:+UseConcMarkSweepGC)。否则，如果所有线程都在 GC 期间停止，您可能会面临长时间的“停止世界”阶段。
The OS should not make a big difference for the GC performance.
操作系统不应对 GC 性能产生太大影响。
You will need of course a 64 bit OS and a machine with enough physical RAM.
您当然需要一个 64 位操作系统和一台具有足够物理 RAM 的机器。
回答by anjanb
here's an article on gc FROM one of Java Champions -- http://kirk.blog-city.com/is_your_concurrent_collector_failing_you.htm
这里有一篇关于 gc 的文章来自 Java Champions -- http://kirk.blog-city.com/is_your_concurrent_collector_failing_you.htm
Kirk, the author writes "Send me your GC logs
Kirk，作者写道“把你的 GC 日志发给我
I'm currently interested in studying Sun JVM produced GC logs. Since these logs contain no business relevent information it should be ease concerns about protecting proriatary information. All I ask that with the log you mention the OS, complete version information for the JRE, and any heap/gc related command line switches that you have set. I'd also like to know if you are running Grails/Groovey, JRuby, Scala or something other than or along side Java. The best setting is -Xloggc:. Please be aware that this log does not roll over when it reaches your OS size limit. If I find anything interesting I'll be happy to give you a very quick synopsis in return. "
我目前对研究 Sun JVM 生成的 GC 日志感兴趣。由于这些日志不包含与业务相关的信息，因此应该可以减轻对保护专有信息的担忧。我只要求您在日志中提及操作系统、JRE 的完整版本信息以及您设置的任何与堆/gc 相关的命令行开关。我还想知道您是否正在运行 Grails/Groovey、JRuby、Scala 或 Java 以外的其他东西或与 Java 一起运行的东西。最佳设置是 -Xloggc:。请注意，此日志在达到您的操作系统大小限制时不会翻转。如果我发现任何有趣的事情，我会很乐意为您提供一个非常快速的概要作为回报。”
回答by tpgould
You should try running visualgc against your app. It′s a heap visualization tool that′s part of the jvmstat download at http://java.sun.com/performance/jvmstat/
您应该尝试对您的应用程序运行 visualgc。它是一个堆可视化工具，是 jvmstat 下载的一部分，位于http://java.sun.com/performance/jvmstat/
It is a lot easier than reading GC logs.
这比阅读 GC 日志要容易得多。
It quickly helps you understand how the parts (generations) of the heap are working. While your total heap may be 10GB, the various parts of the heap will be much smaller. GCs in the Eden portion of the heap are relatively cheap, while full GCs in the old generation are expensive. Sizing your heap so that that the Eden is large and the old generation is hardly ever touched is a good strategy. This may result in a very large overall heap, but what the heck, if the JVM never touches the page, it′s just a virtual page, and doesn′t have to take up RAM.
它可以快速帮助您了解堆的各个部分（代）是如何工作的。虽然您的总堆可能是 10GB，但堆的各个部分会小得多。堆的 Eden 部分的 GC 相对便宜，而老年代的 full GC 则昂贵。调整你的堆的大小，使 Eden 很大，而老年代几乎不被触及，这是一个很好的策略。这可能会导致一个非常大的整体堆，但到底是什么，如果 JVM 从不接触页面，它只是一个虚拟页面，不必占用 RAM。
回答by ShabbyDoo
A couple of years ago, I compared JRockit and the Sun JVM for a 12G heap. JRockit won, and Linux hugepages support made our test run 20% faster. YMMV as our test was very processor/memory intensive and was primarily single-threaded.
几年前，我比较了 JRockit 和 Sun JVM 的 12G 堆。JRockit 获胜，Linux 大页面支持使我们的测试运行速度提高了 20%。YMMV 作为我们的测试非常占用处理器/内存，并且主要是单线程的。
