Сергей Синдеев, Группа «Рексофт» - Hibernate, OOM и ооочень длинные запросы

Подписаться 53 тыс.

Просмотров 2,3 тыс.

50% 1

Ближайшая конференция - Joker 2024, 9 октября (Online), 15-16 октября, Санкт-Петербург
- -
Как бы мы ни хотели, утечки памяти иногда случаются. Рассматриваем, что же такое OOM, как искать его причину и чем могут помочь средства логирования и мониторинга такими средствами, как Kibana и Grafana. Получаем дамп с помощью Spring Actuator и VisualVM. Затем проводим анализ с помощью Eclipse MAT и Intellij IDEA, локализуем утечку. Немного окунаемся во внутреннее устройство Hibernate и рассуждаем о причине утечки.
Скачать презентацию с сайта JPoint - jrg.su/vLgC1q

Наука

Опубликовано:

7 май 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 13

@user-md3xy2kc5l 14 дней назад

Про MAT + работу с хипом, конечно, спасибо, но так и осталось за кадром, что это за чудесные такие запросы с 1кк/2кк параметров в условии IN. Нарезка на батчи, конечно, тут спасла в какой-то мере, но может стоит глянуть в саму логику запроса, почему и зачем он вообще такой нужен? Как будто какой-то JOIN применили. На позапрошлом проекте были DBA и они очень люто и нещадно карали, вот за такие вот IN. Даже какая-то инструкция была, на эту тему, что так делать запрещено. Ну, там и монолит до кучи был... и весьма нагруженный.

@anton-tkachenko 14 дней назад

Я не понял, как запрос слали в базу? Без препаред стейтмента? Почему там сто тыщ миллионов параметров, а не один параметр типа лист?

@tonytissot9372 14 дней назад

лист в качестве параметра (jpql, hql) в конечном запросе (sql) разбивается отдельным параметром для каждого элемента рассказчику на 32:47 предложили передавать массивом, но он сослался на громоздкую реализацию и допиливание диалекта

@anton-tkachenko 13 дней назад

То есть в препаред стейтменте на коннекшене было сто тыщ миллионов аргументов, а не один типа массив?

@tonytissot9372 12 дней назад

@@anton-tkachenko да. притом рассказчик посчитал миллион аргументов нормой, а два миллиона уже нарушением логики т.к. данных в бд меньше)

@user-md3xy2kc5l 11 дней назад

@@tonytissot9372 кстати, интересно было бы понять, почему там этих значений было больше чем записей в БД, вполне возможно там какое-то декартово произведение случилось, обычно в таких случаях DISTINCT применяют, чтобы от дублей избавляться

@alekseyshibayev5243 14 дней назад

На прошлой работе при IN с uuid больше 1000 штук - постгрес кидал исключение. И мы били на батчи. Вот так как у тебя в примере кода. Правда там postgres pro был, и компетентные дба. Может что-то докрутили. А на другом проекте был оракл. У вас какая тут бд была? - Услышал ответ. Обычный постгрес? А что за ентити вы тянете? Простые из одной таблицы? Upd. Полагаю, дба у вас нет?

@user-nl1fi7nx2b 5 дней назад

На простом постгресе делал батчи по несколько тысяч айдишек в IN. Тут скорее проблема в том, что размер батча изначально пустили на самотёк.

@57skies 14 дней назад

instead of MAT, you can use JOL, command line utility that does needs only a fraction of memory to tell you main things about your heapdump. Imagine a dump of 22GB, well you need at least that memory for even open MAT; jol can save you here big time

@realyte6861 14 дней назад

По факту все 30 минут это рассказ о проблеме, а на решение 1 минута. Лучше поподробнее бы рассказали про этот clause parameter padding и какие у него подводные камни. Он по умолчанию выключен и я очень сомневаюсь, что разработчики хибера решили, чтобы каждый сам натолкнулся на OutOfMemory, чтобы его включить

@57skies 14 дней назад

this is the reason we stopped using hibernate a long time ago, and just use plain jdbc. Things are much simpler and far more predictable