Утечка памяти JVM при использовании сборщика G1?

Были ли у кого-нибудь проблемы с утечкой памяти JVM (Hotspot) при использовании сборщика G1?

Я установил размер кучи на 60 ГБ (и -ms, и -ms установлены на 60 ГБ), но размер процесса java (согласно столбцу vsz команды ps) начинается примерно с 64 ГБ, но увеличивается до 84 ГБ. в течение 7 часов.

При использовании параллельного сборщика размер процесса остается стабильным в течение 20 часов работы и составляет около 65 ГБ.

Были ли у кого-нибудь подобные проблемы с коллектором G1? Я запускаю очень простой тест и не использую никакой прямой буферной памяти или другой памяти вне кучи (о которой я знаю).

Версия Java 1.7.0, обновление 5.

(Я поднял ошибку с Oracle по этому поводу, но решил проверить и здесь, если у кого-то есть обходной путь).


java jvm garbage-collection g1gc jvm-hotspot
person Neil    schedule 17.06.2012    source источник
comment
Отправьте свой вопрос по адресу [email protected].   -  person Hot Licks    schedule 18.06.2012
comment
@Neil Можете ли вы сказать нам, какую версию Java вы используете?   -  person alain.janinm    schedule 19.06.2012
comment
@alain.janinm Конечно, это 1.7.0, обновление 5. Я обновил вопрос.   -  person Neil    schedule 19.06.2012
comment
в тесте не участвует прямой буфер (кстати, есть способ получить объем используемой ими памяти), также нет финализации, LinkedList имеет тривиальный размер, поэтому здесь нет проблем. Несколько проблем программирования с самим тестом: для ограниченного LHM вы можете использовать защищенный метод removeEldestEntry, но это не имеет отношения к тесту, есть гонка данных и ненужная синхронизация. обработка статистики. Впрочем, на тест это все никак не влияет.   -  person bestsss    schedule 19.06.2012

Ответы (1)


arrow_upward
1
arrow_downward

Были ли у кого-нибудь подобные проблемы с коллектором G1?

Коротко - да.

вот ТАК тема о причинах утечек памяти:

Создание утечки памяти с помощью Java

он содержит информацию о G1

Использование InflaterInputStream с передачей нового java.util.zip.Inflater() в c-tor (например, PNGImageDecoder) и без вызова end() инфлятора. Что ж, если вы передадите c-tor только с новым, никаких шансов ... и да, вызов close() в потоке не закроет инфлятор, если он передан вручную как параметр c-tor. Это не настоящая утечка, так как она будет выпущена финализатором... когда он сочтет это необходимым. До этого момента он так сильно съедает собственную память, что может привести к тому, что linux oom_killer безнаказанно убьет процесс. Основная проблема в том, что финализация в java очень ненадежная, а G1 до 7.0.2 делала ее еще хуже. Мораль истории: как можно скорее выпустите нативные ресурсы, финализатор слишком плохой.

утечка также упоминается здесь: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7152954

person dantuch    schedule 17.06.2012
comment
Большое спасибо за информацию. Я не использую инфляторы и не вызываю System.gc() явно (и я почти уверен, что я ничего не использую), поэтому я не думаю, что проблемы, которые я вижу, связаны с любой из тех. - person Neil; 18.06.2012
comment
@ Нил, очень сложно сказать, что не так. Утечки памяти - это боль в заднице, всегда :) - person dantuch; 18.06.2012
comment
@ Нил, я тот, кто опубликовал проблему с G1, какую версию вы используете? И самое главное, не течет ли родная память? прямые ByteBuffers похожи на Inflater/Deflater (они используют родную память C/malloc). System.gc() в целом неплохой. Если это не родная память, jmap -histo должно быть достаточно, чтобы отследить проблему. Также, если вы можете опубликовать тест, это было бы полезно. - person bestsss; 18.06.2012
comment
Да, похоже, происходит утечка собственной памяти — это определенно не память кучи, поскольку на протяжении всего теста у меня в куче свободно около 10 ГБ (после того, как произошел сборщик мусора). - person Neil; 18.06.2012
comment
Я не использую прямые буферы байтов напрямую (и мой тест очень прост, поэтому я был бы удивлен, если бы я вызывал что-то, что делает). На всякий случай я установил -XX:MaxDirectMemorySize=1G. Код находится здесь: gist.github.com/2947570 - person Neil; 18.06.2012