я только что с поезда с нодой вышел

это ты зря, получше тырпрайза на jee, имхо. хотя по идее почти всё лучше тырпрайза

пожалуйста, направьте неразумного у меня плей 2.6 в джава-ипостаси, джава 8, постгрес по JDBC поднимаю из базы неск лям записей, делаю объекты, стримлю, выбираю по фильтру штук 1000 на страницу для отображения проблема при этом — выжирает память (дадено 8ГБ), видимо, течёт где-то профилирование показывает: - что мой процесс стартует несколько раз (это, видимо, плеевская акка старается) - что память выделена под кучу char[], byte[], byte[][] понимаю, что это строки, но что именно с ними, хз: - уже настраивал таблицу дедупликации - писал везде .intern() - пробовал разные GC (ParallelOldGC, ParallelGC, G1GC) и даже малость их настраивал направьте, добрые люди, а то башку сломаю между вариантами

Нужно сразу на уровне БД фильтровать.

ты будешь менять пакеты

нет же, значит ты просто не умеешь её готовить, не надо свдить по негативному опыту за всю технологию

оки :) так я тоже умею и делаю, когда можно

проект на нодье с треском провалился

что ты имеешь в виду?

проект на нодье с треском провалился

надо понимать, зачем и почему ты выбираешь какую-то технологию

Ага, и умеешь ли ею пользоваться

в данном случае ты как делаешь?

в моём случае логика на джаве, в базе не могу её выполнить, и проблема не в логике (она быстрая, профиль же делал), а в том, что течёт память по строкам

пожалуйста, направьте неразумного у меня плей 2.6 в джава-ипостаси, джава 8, постгрес по JDBC поднимаю из базы неск лям записей, делаю объекты, стримлю, выбираю по фильтру штук 1000 на страницу для отображения проблема при этом — выжирает память (дадено 8ГБ), видимо, течёт где-то профилирование показывает: - что мой процесс стартует несколько раз (это, видимо, плеевская акка старается) - что память выделена под кучу char[], byte[], byte[][] понимаю, что это строки, но что именно с ними, хз: - уже настраивал таблицу дедупликации - писал везде .intern() - пробовал разные GC (ParallelOldGC, ParallelGC, G1GC) и даже малость их настраивал направьте, добрые люди, а то башку сломаю между вариантами

а как ты понял, что она течет?

из 8ГБ сожрано 8 под char[], byte[], byte[][]

ну это только симптом, а диагноз еще не факт что утечка

ну это только симптом, а диагноз еще не факт что утечка

в JDBC есть поточный режим, пробовал его?

нету, кроме новой либы, которую не пробовал

из 8ГБ сожрано 8 под char[], byte[], byte[][]

не сюда же файлами кидаться

лучше онлайн, если не секретный файл, чтобы другие тоже выразили мнение, я то не эксперт

файл обработки ResultSet мало кто захочет смотреть по этой проблеме, я вангую

файл обработки ResultSet мало кто захочет смотреть по этой проблеме, я вангую

8ГБ под жабу это как-то несерьёзно

Ну и почувствовать что твой код не так уж и плох тоже хороший бонус

я прямо смущаюсь :)

А почему на уровне бд не фильтруешь? Какая логика мешает?

А почему на уровне бд не фильтруешь? Какая логика мешает?

Наверное что то не так в проектировании бд

ещё раз сакцентирую — проблема не в тормозах, проблема в отжирании памяти, зашкаливающем за все разумные границы

-> 8ГБ -> разумные пределы

ещё раз сакцентирую — проблема не в тормозах, проблема в отжирании памяти, зашкаливающем за все разумные границы

Делаешь хипдамп, загружаешь его в mat и смотришь, что за объекты и почему они не выгружаются

char[], byte[], byte[][]

char[], byte[], byte[][]

Кстати а какая у тебя JVM?

char[], byte[], byte[][]

А кто ссылки на них держит?

как бы понять ещё — по хипдампу я не уловил, но 95% уверен, что это строки

Лучше решать проблему в корне, например на уровне бд, чтоб не вытаскивать несколько лямов и оттуда отфильтровать 1000

а вы вообще уверены, что для процессинга такого количества записей вашего размера хватит 8 гб? прикинуть примерный размер памяти как число записей * размеры колонки в БД

Лучше решать проблему в корне, например на уровне бд, чтоб не вытаскивать несколько лямов и оттуда отфильтровать 1000

суть в том, что процессинг стримовый, ему не нужно окружение, один проход — нужно добиться, чтобы работало

это да, знаю, но не вариант

Может у тебя алгоритм O(e^n)?

Чем не вариант?

Читай данные порциями

я стримлю вообще, мне в единицу времени только одна нужна из них

Ну а зачем тогда миллионы читать в память?

Попробуй на 10 жвм запуститься. Там хранение строк оптимизировали

И пускай в процессинг

у меня spliterator, чем не буффер

у меня spliterator, чем не буффер

а какой сплитератор?

Увеличить память вдвое

@pled76 выскажу предположение: попробуйте проверить успевает ли gc убирать те количества объектов, которые создаются и перестают использоваться пока вы грузите данные из базы. Сталкивался с подобным поведением у себя в проекте