Как найти, что Finalizer занимает много времени

Question

Я работаю над приложением, цель которого - вычисление отчетов, как можно быстрее.

Мое приложение использует большой объем памяти; более 100 Go.

С нашей последней версии я замечаю значительное замедление производительности. Мое расследование показывает, что во время вычислений я получаю много сбора мусора между 40 и 60 секундами !!! (JMC говорит мне, что они SerialOld, но я не знаю, что это точно означает) и, конечно же, когда JVM является мусор сбора, применение абсолютно отмороженные

Я сейчас расследующим происхождение этих сборщиков мусора ... и это очень тяжелая работа.

Я подозреваю, что, если эти коллекции мусора настолько долго, это происходит потому, что они много раз проводить в finalize функции (я знаю, что среди всех библиотек мы интегрируем от других команд, некоторые из них используют финализаторы)

Однако я не знаю, как сопоставить (или нет) эту гипотезу; Как найти, какой финализатор занимает много времени.

Ищу хороший инструмент или даже хорошую методологию

Вот данные, собранный с помощью JVisualVM

Как вы можете видеть, у меня всегда есть много «Pending Финализаторов», когда у меня есть a log Old Garbage

Удивительно то, что при использовании JVisualVM приведенный выше график регулярно прокручивается справа налево. Когда старый мусор срабатывает, прокрутка останавливается (пока здесь, это нормально, это конец света). Однако, когда прокрутка внезапно перезагружается, он делает не с конца старого мусора, но с конца Pending Serializer

Это позволяет мне думать, что финализаторы преграждали виртуальная машина

ли кто-нибудь имеет объяснений для это?

Большое спасибо Philippe

Answer 1

Вот что я хотел бы сделать, чтобы исследовать вашу теорию финализации.

1. Запустите JVM, используя ваш любимый Java-профайлер.

2. Оставьте его работать достаточно долго, чтобы получить полную кучу.

3. Запустите профайлер.

4. Trigger сбор мусора.

5. Остановить профайлер.

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

---

Однако, я подозреваю, что реальная проблема будет утечка памяти, и что ваша JVM получает до точки, где кучи заполнения с unreclaimable объектов. Это может объяснить частые коллекции мусора SerialOld.

В качестве альтернативы, это может быть большой проблемой кучи. 100Gb ... большой.

Answer 2

Мое приложение использует большой объем памяти; более 100 Go.

JMC говорит мне, что они SerialOld, но я не знаю, что это точно означает

Если вы используете серийный коллектор для 100GB кучи затем длинные паузы следует ожидать, поскольку серийный коллектор однопоточное и одно ядро ​​может только сжимать столько памяти за единицу времени.

Просто выберите один из многопоточных коллекторов, чтобы обеспечить меньшее время паузы.

Однако я не знаю, как конфликтовать (или нет) эту гипотезу; Как найти, какой финализатор занимает много времени.

Вообще: собрать больше данных. Для связанных с GC вещей вам необходимо включить GC-протоколирование, за время, затраченное на Java-код (будь то ваше приложение или сторонние библиотеки), вам нужен профилировщик.