Частая полная сборка мусора и восстановление нуля во время сборки мусора в Минор

В одном из моих производственных приложений мы используем Oracle JRockit как JVM. Незначительная частота GC очень высокая (примерно каждые 40 секунд). Но какое-то время мы видим частый полный сбор мусора, и в течение этого времени второстепенный сборщик мусора также восстанавливает незначительные байты. что приводит к сбою приложения, так как наше приложение должно отвечать в течение 1 секунды, а полные паузы GC занимают более 1 секунды.

У меня есть некоторые наблюдения из журналов GC. 1 - Minor GC не может вернуть какие-либо байты в течение этого периода, кроме определенного периода. Minor GC восстанавливает почти 95-99 процентов питомников (кроме зоны хранения). 2- Я наблюдаю Запрошено аварийное параллельное сканирование во время фазы уплотнения.

Моя конфигурация кучи

Heap            : 10 GB
Nursery         : 1GB
GC              : gencon
Keeparea        : 50%
CompactionRatio : 10%
gcTrigger       : 40%

Мы попытались изменить размер детской на 2 ГБ и 3 ГБ, где частота проблем уменьшилась на 2 ГБ и увеличилась на 3 ГБ.

Любая помощь, почему эта проблема вызвана или как исследовать это дальше

Обновление 1:

Я включил модуль memdbg для сборщика мусора и обнаружил, что запускается полный сборщик мусора, потому что количество деталей для детской комнаты превышает установленный по умолчанию предел 10000, но я вижу, что OC также оставляет большое количество деталей в детской. Любые указания в этом вопросе


java memory-leaks memory-management garbage-collection jrockit
person Nishant Modi    schedule 27.09.2017    source источник
comment
У меня довольно слабый опыт работы с JRockit. Однако на вашем месте я бы попытался лучше понять степень заполнения различных областей памяти. Не зная встроенных инструментов JRockit (я бы предложил JConsole с HotSpot), я мог бы указать вам на YourKit, который предлагает 15-дневную пробную версию, которой должно быть достаточно, чтобы понять, какие области памяти переполнены.   -  person Jonathan    schedule 31.10.2017

Ответы (1)


arrow_upward
0
arrow_downward

Итак, мы решили эту проблему, чтобы разобраться в проблеме, мы включили подробный модуль memdbg, который предоставил нам информацию о том, почему срабатывает сборщик мусора. Полный GC запускался по причине сбоя запроса на выделение, что, согласно документации Oracle, происходит, когда дочерняя часть кучи фрагментирована, поскольку они добавили проверку из R28.2.5 для проверки всех частей в детской во время каждого второстепенного GC, и если это больше, чем определено limit (по умолчанию 10 КБ) Незначительный сборщик мусора будет прерван, а полный сборщик мусора будет запущен с ошибкой запроса на выделение памяти.

Чтобы решить эту проблему, мы добавили параметр ниже, чтобы отключить эту проверку, после чего система будет работать нормально.

-XXNurseryPartsLimits=0
person Nishant Modi    schedule 01.11.2017