Есть ли инструменты для отслеживание памяти для Spring?

Question

[vitya_brodov]

Есть ли инструменты/библиотеки для отслеживание утечки памяти для Spring boot чтобы избежать на раннем стадии OOM heap space?

Answer 1

[Андрей Шишкин]

Spring Metrics Actuator
https://spring.io/guides/tutorials/metrics-and-tracing/
https://www.baeldung.com/spring-boot-actuators

Answer 2

[Dmitry Roo]

VisualVm есть. Для всей jvm.

Answer 3

[mayton2019]

Нет таких инструментов. Утечка памяти - неформализована в терминологии Java.

Но ее последствия видны в виде невозможности освободить память в какой-то момент времени в runtime.
Причиной может быть некий глобальный статический объект который хранит в себе коллекции других объектов.
Но такое программирование не запрещено. Просто надо хотя-бы знать в лицо такие глобальные объекты. Обычно это сингтоны, бины. Поскольку они - вечные - то и GC убирать их не будет.

На ранних этапах можно делать memory-dump вашего приложения и анализировать его через Eclipse Memory
analyzer. Там в виде гистограммы публикуется использование памяти и количество объектов. Через него например
я видел как по хамски себя ведет postgres JDBC драйвер во время выборки.

Comments

[vitya_brodov]

я видел как по хамски себя ведет postgres JDBC драйвер во время выборки

Как Вам удалось решить проблему в итоге?

P.s У меня судя по Графане, при извлечения сущностей из бд кроном, затем после обновлении этих сущностей и сохранений обратно в бд, объекты не умирают...

[mayton2019]

vitya_brodov, по поводу JDBC. Информация - по состоянию где-то на 2019 год. После этого я не тестил.
Мы обратили внимнание на переполнение памяти при процедурах массовой выгрузки из Postgres. Я анализировал через Eclipse/MA и заметил что по количеству штук лидируют jdbc.datarows входящие в namespace драйвера Postgres. Причем это были не наши бизнес-объекты а именно объекты самого драйвера. При том что внутри цикла мы наши объекты пере-используем. Тоесть не накапливаем.

Было 2 варианта фикса.
- читать пачками (хотя-б по 10000 строк) и закрывать курсор. Это форсировало удаление драйверных tuples, но замедляло execution на стороне БД потому что нам надо было фиксировать окно с сортировкой. Партишенинга не было. База была не наша и реструктурировать таблицу мы не могли.
- открывать курсор с опцией FORWARD и еще с какой-то второй. Не помню. В этом случае JDBC tuples не накапливались в памяти Java но сильно падала скорость выгрузки (2-3 раза). Возможно медленно шел FETCH.

Какое решение было применено я уж не помню. Для нас проект закончился с точки зрения активной разработки. Перевели в поддержку.

UPD.

Answer 4

[Орхан Гасанлы]

Доброго времени суток.
Есть много разных инструментов, в том числе, как коллега подсказал visualVM.
Если используете İntellij İDEA, то в него встроены некоторые инструменты для профайлинга.
Если вам необходимо провести удаленный профайлинг, то можете еще воспользоваться возможностями удаленного дебага (Intellij IDEA -> Remote JVM debug)