与使用的%相比,意外的堆大小意外

Question

有一个内存分配问题,我希望你的帮助.我们已经分析了一些顶级服务,我们注意到它们的RES值约为1.8GB,据我所知,这意味着他们当时正在保持1.8GB的内存.如果我们刚刚启动它们(它们基本上是从缓存中读取,进行处理,然后推送到另一个缓存),这样会好的,但是看到我们在CPU密集型处理完成后仍然看到这个,我们想知道它是否意味着某些东西没有像我们预期的那样被GC.

我们使用以下参数运行程序:-Xms256m -Xmx3096m,据我所知,初始堆大小为256,最大堆大小为3096.

现在我会希望看到的是堆成长为最初需要,再缩根据需要为内存变释放(虽然这可能是我的第一个错误).我们实际看到的jvisualvm如下:

• 3分钟:用过的堆是1GB,堆大小是2GB
• 5分钟后:我们已经完成了处理,所以使用堆大幅下降到接近足够的zilch,堆大小但是只下降到大约1.5GB
• 7分钟 - >:周期性的小位实时处理,使用堆只在100-200MB左右,但堆大小保持恒定在1.7GB左右.

我的问题是,为什么我的堆没有像我预期的那样缩小？这不是抢夺Linux盒子上有价值的内存的其他进程,如果是这样,我怎么能解决它？我们有时会看到内存错误,并且这些进程被分配了最"意外"的内存大小,我认为最好从它们开始.

干杯,戴夫.

(请原谅我们对JVM内存调整缺乏了解!)

Answer 1

您可能想查看有关调整堆扩展和收缩的答案。默认情况下，JVM 不会过于积极地收缩堆。此外，如果堆在很长一段时间内有足够的可用空间，它不会触发GC，我相信这是唯一考虑收缩它的时候。

理想情况下，您将最大值配置为一个值，该值可以在满负载下为您的应用程序提供足够的空间，但如果始终都在使用，则操作系统性能可以接受。为了可预测性和潜在的更好性能而将最小值设置为最大值的情况并不罕见（我对此没有任何参考）。