Кучи Java продолжает сокращаться! Что происходит в этом графике размера кучи?

Question

Это снимок экрана JVM (win64, 6u17), на котором выполняется ActiveMQ, после каждой сборки мусора размер кучи уменьшается. По мере уменьшения размера кучи сбор мусора происходит чаще, а куча уменьшается быстрее. В конце концов, виртуальная машина зависает, тратя все свое время на сборку.

-Xms является значением по умолчанию, а -Xmx составляет 2048 МБ.

Что происходит !!? Как я могу избежать этого?

http://imagebin.org/92614

Сжимающаяся куча http://imagebin.org/index.php?mode=image&id=92614

n.b, первоначально размещенный на serverfault.com, перемещен на stackoverflow.com по запросу

Answer 1

Google нашел меня из FAQ по IBM JVM (как это для NLA):

Когда уменьшается куча Java?

Сжатие кучи происходит, когда GC определяет, что имеется много свободного места в куче, и освобождение некоторой памяти кучи полезно для производительности системы. Сжатие кучи происходит после GC, но когда все потоки все еще приостановлены.

Sun JVM делает нечто подобное. Ниже приведен отрывок из статьи Oracle Technology Network, озаглавленной Эргономика в виртуальной машине Java 5.0 .

Куча будет расти или уменьшаться до размера, который будет поддерживать выбранную цель пропускной способности. Можно ожидать некоторые колебания размера кучи во время инициализации и во время изменения поведения приложения.

...

Типично, что размер кучи будет колебаться, когда сборщик мусора пытается удовлетворить конкурирующие цели. Это верно, даже если приложение достигло устойчивого состояния. Давление для достижения цели по пропускной способности (которая может потребовать большей кучи) конкурирует с целями за максимальное время паузы и минимальную занимаемую площадь (что может потребовать небольшой кучи).

Я предлагаю вам взглянуть на остальную часть этого документа; он может содержать больше информации, имеющей отношение к вашей проблеме.

Answer 2

Существует аргумент JVM, который управляет изменением размера кучи.

-XX: MaxHeapFreeRatio

Значение по умолчанию для этого равно 70. Свободное отношение - это количество пространства, не выделенного в куче, по общему размеру кучи. Если процент свободного места превышает 70% по умолчанию, jvm уменьшит размер кучи, чтобы ОС могла использовать память.

Если куча сокращается слишком часто, вы можете увеличить значение -XX: MaxHeapFreeRatio. Предположительно, если он установлен на 100, он никогда не будет пропускать.

Answer 3

Просто предположение: Похоже, система в значительной степени простаивает. Возможно, происходит некоторое кеширование, и содержимое выпадает из кеша и получает gc'd. Или, поскольку это система массового обслуживания, может быть, в ней есть несколько сообщений, которые медленно доставляются и впоследствии обрабатываются gc'd.

Увеличение частоты прогонов gc может быть связано с уменьшением нагрузки на систему.

Что касается того, как этого избежать. Почему вы хотите избежать этого? Похоже, загрузка вашего процессора равна нулю. Так что вы можете позволить gc делать все, что он хочет