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

Рет қаралды 2,446

22 күн бұрын

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

Пікірлер: 13

@user-md3xy2kc5l 20 күн бұрын

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

@alekseyshibayev5243 19 күн бұрын

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

@user-nl1fi7nx2b 11 күн бұрын

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

@anton-tkachenko 20 күн бұрын

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

@tonytissot9372 20 күн бұрын

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

@anton-tkachenko 18 күн бұрын

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

@tonytissot9372 18 күн бұрын

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

@user-md3xy2kc5l 17 күн бұрын

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

@57skies 19 күн бұрын

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 19 күн бұрын

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

@57skies 19 күн бұрын

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 18 күн бұрын

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