Как избежать долгих пауз GC при создании множества мелких объектов?

Question

[jDekx]

Добрый день.

Имеется сервер, который выполняет вычисления поиска пути. Для каждого вычисления создается локальная HashMap, в которую записываются мелкие объекты Node (порядка 50 байт на Node и 50 байт на Position, который является полем Node).

Сервер запускается с параметрами

-Xmx12g
-Xms1g
-server
-XX:+UseParallelGC

При этом серверу, судя по VisualVM памяти хватает, но паузы GC приводят к зависанию, если я правильно понимаю.





Что я делаю не так, и как можно избежать столь долгих пауз?

Comments

[Максим Мосейчук]

Что за профилировщик?

[jDekx]

Java Mission Control (JMC).

Answer 1

[jDekx]

Все починилось. Допущенная ошибка в коде, в процессе рефакторинга, которую не покрывали тесты. Основной поток стал обрабатывать слишком много узлов, игнорируя проверку на максимально-допустимое количетсво. Это привело к сильному росту потребления памяти, при этом другие потоки успешно выполняли свою работу и GC подчищал память за ними. Это меня запутало, т.к. судя по графику память иногда, да очищалась.

Просмотрел количество объектов Node и очередей, в которых они хранятся, выяснилось, что на одну очередь приходится порядка 10'000'000 Node, это значение сильно больше максимально-допустимого. После исправления ошибки, основной поток стал корректно выполнять свою задачу, рост памяти и вызов GC перестали быть проблемой.

График памяти после решения проблемы:

Answer 2

[Antony]

Как вариант - избегать освобождения и выделения памяти. Особенно частого и в больших количествах.

Очевидно что ноды будут изменяться только если изменяется сам уровень (ну или перемещаются какие-то объекты, которые влияют на проходимость карты) и очевидно это будут небольшие (относительно общего кол-ва нод) изменения, соответственно вы можете иметь глобальный пул нод и в локальной хешмапе использовать ссылки на нужные вам ноды. Как результат - ваши ноды быстро перестанут быть молодыми объектами и GC не будет их проверять (или будет, но редко. Этот момент я не очень понял из оракловской доки)

Еще есть вариант - использовать другой сборщик. Дока

И еще на хабре советуют увеличить размер PermanentGeneration

Comments

[jDekx]

Куча Node создается непосредственно при поиске пути - алгоритм A*. После выхода из метода поиска, все эти объекты могут быть удалены.

Изначально пробовал без указания сборщика (jdk 11, сборкщик G1 по умолчанию), но с ним все еще раньше зависало.

Статью изучу, по результатам отпишусь, спасибо!

[Antony]

После выхода из метода поиска, все эти объекты могут быть удалены.

А зачем? У вас набор вершин графа, ребер и весов ребер не меняется. Меняется только начальная и конечная вершины и статус открытости/закрытости и счетчик пройденного пути. (т.е. только поля объектов) Соответственно вам требуется только изменять вершины, не создавая новых и не удаляя старых. Т.е. первым делом вы сбрасываете состояние всех незакрытых соседей, а потом уже работает как работали.

[Antony]

Или как альтернативный вариант - имейте пул нод и когда вам нужна "еще одна нода" берите ее из пула, сбрасывайте состояние и работайте как работали, а когда она перестала быть нужной - возвращайте ноду в пул. (как варинат - сбрасывать состояние при помещении ноды в пул).

Весьма вероятно что присвоение значения "по-умолчанию" части полей быстрее, чем создание нового объекта с инициализацией всех его полей.

[jDekx]

Открытость/закрытость узла определяется в какой из HashMap он хранится. Судя по снимку памяти, больше всего занимает объект позиции, который создается, иногда, лишний раз. Там все немного сложнее - вершины графа хранятся в других объектах, а Node создаются непосредственно при поиске пути. Так же в требованиях работа этого всего в многопоточном режиме, поэтому пул придется блокировать на время получения/возвращения узлов. В дальнейшем буду пробовать оптимизировать использование памяти, на данном этапе это не требуется.

Параметры PermGen в jdk 11 отсутствуют, поэтому эта опция не спала. Проблему и решение описал в ответе.

Спасибо за помощь!

[AlexHell]

так ремарка

Так же в требованиях работа этого всего в многопоточном режиме, поэтому пул придется блокировать на время получения/возвращения узлов.

сделайте пул на каждый поток - и будет без блокировки и потокобезопасно
а еще лучше - в отдельно потоке обрабатывайте задачи типа поискПути, например через очередьЗадач, так и пул всего 1 будет