Почему сборщик мусора не выполняет более агрессивную сборку мусора раньше, чем однозначный процент свободной кучи?

Вот мои настройки кучи JVM Sun Hotspot 1.6 в WebLogic 11g:

-Xms10g -Xmx10g -XX:MaxPermSize=256m -XX:+UseParNewGC -XX:ParallelGCThreads=2 -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:ConcGCThreads=2

То, что я вижу на графике % без кучи JVM за 24 часа, в основном % без кучи снижается с медленной скоростью, пока мы не достигнем около 9% (занимает около 24 часов). Затем система запускает то, что выглядит как полный gc, и возвращается к 97%.

Есть ли какой-то параметр, который я должен добавить/изменить, который скажет JVM выполнить этот полный GC раньше, чем когда мы получим менее 10% свободной кучи? например какая-то настройка соотношения?

Не вызывает проблем то, что он ждет, пока мы не освободимся до 9%, но это усложняет мониторинг/предупреждение. В идеале мы хотим всегда оставаться выше, чем, скажем, 30% бесплатно, чтобы, если мы опустимся до этих однозначных чисел, мы знали, что есть какая-то проблема, например. утечка памяти.


java profiling garbage-collection
person BestPractices    schedule 11.10.2012    source источник
comment
Из того, что я понимаю о сборке мусора Java, он может собираться бесплатно, когда захочет, если захочет. Вы можете вызвать system.gc, чтобы вручную сообщить сборщику мусора, что у вас есть вещи, которые он должен освободить, но gc не должен этого делать.   -  person andre    schedule 11.10.2012
comment
Вы можете использовать команду System.gc() для ручной сборки мусора.   -  person Tristan Hull    schedule 11.10.2012
comment
Вам нужно посмотреть, сколько памяти используется/свободно после полного GC. В противном случае свободное пространство бесполезно для мониторинга.   -  person Peter Lawrey    schedule 11.10.2012
comment
System.gc() не запускает сборщик мусора окончательно, он предлагает запустить его. Это не детерминировано.   -  person matt b    schedule 11.10.2012
comment
@BestPractices, я бы посоветовал больше подумать о почему этого вопроса - я думаю, вы делаете неверное предположение, что наличие ‹ 30% свободной кучи указывает на утечку памяти. Если вы предоставите JVM X объем кучи, он будет стремиться использовать как можно больше этой кучи - насколько известно JVM, вы согласны с тем, что он использует до 10G пространства. Лучшее указание на утечку — это когда полные GC не могут освободить пространство или когда объем освобождаемого пространства со временем становится все меньше и меньше, что не так легко отслеживать автоматически.   -  person matt b    schedule 11.10.2012
comment
Я не говорю, что это указывает на утечку памяти. Я просто хочу, чтобы он собирал мусор раньше, чтобы я мог установить лучшие пороги мониторинга. Прямо сейчас он падает до 9% свободного места (что опять же занимает очень много времени, чтобы добраться до него), а затем мне нужно подождать и посмотреть, вернет ли GC его обратно до 97%. Я бы предпочел, чтобы он проводил более частые полные сборщики мусора, чем что бы он ни делал прямо сейчас.   -  person BestPractices    schedule 11.10.2012

Ответы (2)


arrow_upward
2
arrow_downward

Нашел ответ, используя комбинацию других статей stackoverflow.

-XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=N

где N — примерно, какой процент занятости вызовет полный сборщик мусора. Значение по умолчанию ~ 92, поэтому я вижу, что полный GC свободен на 9%. Переключение на 65 сработало для моего варианта использования. Полная сборка мусора происходит примерно на 35% бесплатно.

person BestPractices    schedule 11.10.2012

arrow_upward
0
arrow_downward

Как насчет удаления: -Xms10g и последующего мониторинга общего размера кучи? Это также приведет к тому, что сборщик мусора будет запускаться чаще.

Если ваше приложение действительно использует только 300 МБ оперативной памяти (3%), то кажется экстремальным начинать с выделения 10 гигабайт.

person MTilsted    schedule 11.10.2012
comment
На коробке 128 ГБ оперативной памяти. Может также работать с кучей 10 ГБ. Бывают случаи, когда данные, загруженные в приложение, значительны (в ГБ), поэтому нам нужны дополнительные накладные расходы. Мы начали с размера кучи по умолчанию, а затем увеличили его, чтобы учесть ошибки OutOfMemory в определенных случаях использования. Таким образом, максимальный размер 10 ГБ остается. - person BestPractices; 11.10.2012
comment
Я не хочу предлагать вам изменить максимальную настройку. Я комментировал -Xms10G, что означает: начните с выделения 10 г. Без этого куча сначала будет меньше, а затем вырастет до 10 г, если и когда вам это нужно. Это должно упростить мониторинг использования памяти. - person MTilsted; 11.10.2012