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
Про MAT + работу с хипом, конечно, спасибо, но так и осталось за кадром, что это за чудесные такие запросы с 1кк/2кк параметров в условии IN. Нарезка на батчи, конечно, тут спасла в какой-то мере, но может стоит глянуть в саму логику запроса, почему и зачем он вообще такой нужен? Как будто какой-то JOIN применили. На позапрошлом проекте были DBA и они очень люто и нещадно карали, вот за такие вот IN. Даже какая-то инструкция была, на эту тему, что так делать запрещено. Ну, там и монолит до кучи был... и весьма нагруженный.
По факту все 30 минут это рассказ о проблеме, а на решение 1 минута. Лучше поподробнее бы рассказали про этот clause parameter padding и какие у него подводные камни. Он по умолчанию выключен и я очень сомневаюсь, что разработчики хибера решили, чтобы каждый сам натолкнулся на OutOfMemory, чтобы его включить
На прошлой работе при IN с uuid больше 1000 штук - постгрес кидал исключение. И мы били на батчи. Вот так как у тебя в примере кода. Правда там postgres pro был, и компетентные дба. Может что-то докрутили. А на другом проекте был оракл. У вас какая тут бд была? - Услышал ответ. Обычный постгрес? А что за ентити вы тянете? Простые из одной таблицы? Upd. Полагаю, дба у вас нет?
лист в качестве параметра (jpql, hql) в конечном запросе (sql) разбивается отдельным параметром для каждого элемента рассказчику на 32:47 предложили передавать массивом, но он сослался на громоздкую реализацию и допиливание диалекта
@@tonytissot9372 кстати, интересно было бы понять, почему там этих значений было больше чем записей в БД, вполне возможно там какое-то декартово произведение случилось, обычно в таких случаях DISTINCT применяют, чтобы от дублей избавляться
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
Про MAT + работу с хипом, конечно, спасибо, но так и осталось за кадром, что это за чудесные такие запросы с 1кк/2кк параметров в условии IN. Нарезка на батчи, конечно, тут спасла в какой-то мере, но может стоит глянуть в саму логику запроса, почему и зачем он вообще такой нужен? Как будто какой-то JOIN применили. На позапрошлом проекте были DBA и они очень люто и нещадно карали, вот за такие вот IN. Даже какая-то инструкция была, на эту тему, что так делать запрещено. Ну, там и монолит до кучи был... и весьма нагруженный.
По факту все 30 минут это рассказ о проблеме, а на решение 1 минута. Лучше поподробнее бы рассказали про этот clause parameter padding и какие у него подводные камни. Он по умолчанию выключен и я очень сомневаюсь, что разработчики хибера решили, чтобы каждый сам натолкнулся на OutOfMemory, чтобы его включить
На прошлой работе при IN с uuid больше 1000 штук - постгрес кидал исключение. И мы били на батчи. Вот так как у тебя в примере кода. Правда там postgres pro был, и компетентные дба. Может что-то докрутили. А на другом проекте был оракл. У вас какая тут бд была?
- Услышал ответ. Обычный постгрес?
А что за ентити вы тянете? Простые из одной таблицы?
Upd. Полагаю, дба у вас нет?
На простом постгресе делал батчи по несколько тысяч айдишек в IN. Тут скорее проблема в том, что размер батча изначально пустили на самотёк.
Я не понял, как запрос слали в базу? Без препаред стейтмента?
Почему там сто тыщ миллионов параметров, а не один параметр типа лист?
лист в качестве параметра (jpql, hql) в конечном запросе (sql) разбивается отдельным параметром для каждого элемента
рассказчику на 32:47 предложили передавать массивом, но он сослался на громоздкую реализацию и допиливание диалекта
То есть в препаред стейтменте на коннекшене было сто тыщ миллионов аргументов, а не один типа массив?
@@anton-tkachenko да. притом рассказчик посчитал миллион аргументов нормой, а два миллиона уже нарушением логики т.к. данных в бд меньше)
@@tonytissot9372 кстати, интересно было бы понять, почему там этих значений было больше чем записей в БД, вполне возможно там какое-то декартово произведение случилось, обычно в таких случаях DISTINCT применяют, чтобы от дублей избавляться
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
same, we are using sql with jooq, hibernate is a garbage
Да jpoint нынче не тот