Неожиданно большой размер кучи по сравнению с используемым%

Question

Есть вопрос о выделении памяти, с которым я хотел бы получить вашу помощь. Мы проанализировали некоторые из наших лучших сервисов и отметили, что они имеют значение RES около 1,8 ГБ, что, насколько я понимаю, означает, что в то время они держали 1,8 ГБ памяти. Что было бы хорошо, если бы мы только запустили их (они, по сути, читают из кеша, выполняют обработку и отправляют в другой кеш), но, видя, как мы все еще видим это после завершения обработки, интенсивно использующей процессор, мы задаемся вопросом: означает, что что-то не так, как мы ожидали.

Мы запускаем программу со следующими параметрами: -Xms256m -Xmx3096m , что, как я понимаю, означает начальный размер кучи 256 и максимальный размер кучи 3096.

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

• 3 минуты: использованная куча - 1 ГБ, куча размер 2ГБ
• 5 минут: мы закончили обработку, так использованная куча резко падает почти достаточно пшик, размер кучи однако только падает до 1,5 ГБ
• 7 минут ->: маленькие биты реального времени периодически обрабатывая, использовал кучу только между 100-200 МБ или около того, однако размер кучи остается постоянным около 1,7 ГБ.

Мой вопрос будет таким: почему моя куча не уменьшилась, как я, возможно, ожидал? Разве это не отнимает у других процессов на коробке с linux ценной памяти, и если да, то как я могу это исправить? Иногда мы видим ошибки нехватки памяти, и, поскольку этим процессам выделяется самый «неожиданный» объем памяти, я подумал, что лучше начать с них.

Cheers, Дэйв.

(~ прошу прощения за возможное отсутствие понимания по настройке памяти JVM!)

Answer 1

Возможно, вы захотите увидеть этот ответ о настройке расширения и сжатия кучи.По умолчанию JVM не слишком агрессивна в отношении сокращения кучи.Кроме того, если в куче достаточно свободного места в течение длительного периода времени, он не будет запускать сборщик мусора, что, я полагаю, единственное время, которое рассматривается для его сокращения.дает вашему приложению достаточный запас при полной нагрузке, но при этом приемлем для производительности ОС, если она всегда использовалась.Нередко устанавливают минимум на максимум для предсказуемости и, возможно, лучшей производительности (у меня нет ничего, на что можно было бы сослаться на этот случай).

Answer 2

У меня нет полного ответа, но подобный вопрос был задан до .Из предыдущего обсуждения вы должны изучить -XX:MaxHeapFreeRatio= в качестве параметра настройки для принудительного освобождения кучи обратно в операционную систему.Здесь есть документация , и я считаю, что значение по умолчанию позволяет очень большому количеству неиспользованной кучи оставаться в собственности JVM.

Answer 3

Возможно, вы могли бы попробовать профилирование с помощью TPTP, visualvm или JProbe (коммерческое, но пробное), чтобы точно узнать, что происходит.

Другая вещь, на которую стоит обратить внимание - это обработчики файлов; У меня нет подробностей, но один из моих коллег несколько лет назад столкнулся с проблемой насыщения кучи, вызванной процессом, который открыл много файлов, и обнаружил, что каждый раз, когда он открывал один, в собственной куче выделялся буфер 4 КБ, освобождается в конце его обработки. Я надеюсь, что это довольно смутные признаки могут помочь ...

Answer 4

Ну, GC не всегда работает, когда вы думаете, и он не всегда собирает то, что разумно. С таким же успехом он может начать собирать объекты из пространства старого поколения, только если у него почти не осталось места в куче (поскольку сбор из старого поколения обычно включает в себя коллекцию «останови мир», которую ГК пытается избежать до тех пор, пока это действительно не потребуется это).