JVM 最小堆大小推荐原因?

发布于 2024-12-03 19:32:54 字数 273 浏览 2 评论 0原文

BEA 建议保持最小和最大堆大小相同。他们没有详细说明提出该建议的原因。有人可以提供详细信息吗?

我还从一位架构师那里得到了另一条建议,即不要设置任何最小值,而只设置最大值。对此有何评论?如果我不使用它,默认值是什么?

监视和调整 JVM 设置的最佳工具是什么?我在 BEA weblogic 10g 上使用 JDK1.6。它在 Linux 32 位 JVM 上。

最大堆大小设置为 2GB 有用吗?服务器有大量 RAM。目前设置为1.5GB,40个并发用户时使用率为80%。 谢谢,

BEA recommends to keep both min and max heap sizes same. They didn't elaborate the reason for the suggestion. Can someone provide details?

I also got another recommendation from an architect of not setting anything for minimum and just set the maximum. Any comments on this? If i dont use it, what would be the default?

What is the best tool to monitor and tune JVM settings. I am using JDK1.6, on BEA weblogic 10g. It is on Linux 32bit JVM.

Is Max heap size set to 2GB any good? Server has lots of RAM. Currently it is set at 1.5GB, and it is at 80% usage when there is 40 concurrent users.
Thanks,

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

烟花易冷人易散 2024-12-10 19:32:54

当 JVM 需要增加堆的大小时,它将调用完整的垃圾收集,这可能会降低吞吐量或导致暂停,因此我认为出于性能原因,他们建议这样做。

默认值记录为 2MB,因此如果如果不重写它,由于堆的大小经常调整,启动后您可能会得到很多(可能非常快)完整的集合。

除非您试图使内存占用量尽可能小,否则我会遵循 BEA 的建议。

从给出的信息中无法判断 2GB 是否合适,或者占用其中空间的对象是否仍在范围内 - 老年代将逐渐填满,直到调用完整集合时空间耗尽。这80%的数字从何而来?

使用以下 JVM 参数将 GC 详细信息记录到名为 gc.log 的文件中:

-verbose:gc -XX:+PrintGCDetails -Xloggc:gc.log 

然后您可以使用 http://www.tagtraum.com/gcviewer.html

When the JVM needs to increase the size of the heap it will invoke a full garbage collection which may reduce throughput or cause a pause, so I would think that this is recommended by them for performance reasons.

Default value is documented as 2MB so if you don't override it you are likely to get a lot of (probably very quick) full collections after starting up as the heap is frequently resized.

Unless you are trying to keep the memory footprint as small as possible, I would follow BEA's advice.

Impossible to say from the information given if 2GB is appropriate, or if the objects that are using up space in it are still in scope - the old generation will just gradually fill up until it runs out of space when a full collection will be invoked. Where does that 80% figure come from?

Use the following JVM arguments to log GC details to a file called gc.log:

-verbose:gc -XX:+PrintGCDetails -Xloggc:gc.log 

Then you can analyse this using something like http://www.tagtraum.com/gcviewer.html

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文