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

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

[@57skies]

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

[@user-md3xy2kc5l]

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

[@alekseyshibayev5243]

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

[@user-nl1fi7nx2b]

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

[@57skies]

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

[@UniXoiD69]

same, we are using sql with jooq, hibernate is a garbage

[@anton-tkachenko]

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

[@tonytissot9372]

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

[@anton-tkachenko]

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

[@tonytissot9372]

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

[@user-md3xy2kc5l]

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

[@realyte6861]

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

[@vladiksun1985]

Да jpoint нынче не тот