Загрузчик xml в БД на базе sax-парсера.
Маленькие файлы (неск. сот метров) грузятся без проблем, но они могут достигать и 2Гб.
И когда начинаешь грузить большой файл, то чем дальше, тем ощутимее, что чтение идет медленнее, при этом судя по картинке,
растет и число используемой памяти, хотя казалось бы после executeBatch и clearBatch, все что прочиталось должно бы ведь сброситься, а тут такие дела (не видно ощутимого освобождения памяти):

При этом все что можно стараюсь закрывать в блоках финализации или try с ресурсами, но ощущение, что где-то утекает.

Как бы быстро понять/отловить что именно? ) (например, может я не чищу, что-то, что должен бы чистить, т.е. увидеть, экземпляры каких классов копятся в памяти или еще как-то понять почему расход увеличивается, или может сакс-парсер читает файл как бы не "окном", а постепенно весь загружается в память?:))

И еще, можно ли как-то в профилировщике понять не по методам, а в разрезе операторов метода, что именно тормозит.
(т.е. есть метод, который жрет много времени, хочется понять что именно в нем тяжелое, можно самому внутри метода позасекать время, но это ж как-то неудобно и не всегда может быть корректно имхо)

Blazkowicz, спасибо, вроде бы нашел. Правда не научным методом.
Все параметры для стейтментов собираю по мере чтения в хэштаблице.
И есть одно поле, которое может достигать неск. мегабайт данных типа clob.
Соответственно в хэштаблицу пихаю его в String, но делаю это видимо некорректно:
пока сакс парсер читает значение этого поля, много раз генерится событие


Ну и я каждый раз для этого поля достаю из таблицы уже сохраненную строку и тупо прицепляю к ней то, что еще прочитал:


Когда закаментил эту конкантенацию, то все зашуршало оч. быстро и с памятью проблем не стало.
Помимо нюансов возможных утечек такого способа, есть ощущение, что надо тем же стрингбилдером собрать до конца это большое поле, а потом уже один раз засунуть в массив параметров (как и делаю с другими полями):

BlazkowiczНужно не собирать строку воедино, а писать в OutputStream, который бы напрямую был связан с БД.
Это как? Есть примеры такой загрузки?
Я ж через jdbc, берешь его стейтмент, туда инсерт, прописываешь параметры, addBatch + executeBacth.

Пока поправил на стрингбилдер и все полетело с какой-то даже пугающей скоростью и с памятью нормуль вроде )

BlazkowiczНо как подружить это с батчами, надо подумать.
Не ну там как понял, пример чтения в поток по сути из курсора?
В обратном направлении было бы круто наверно, но пока не представляю реально ли )
А пока добился, гигабайтный файл залезает в базу за 5минут, что меня более чем устраивает и даже радует )

Еще засада.
Столкнулся с тем, что при массовой загрузке падаю на нехватке временного пространства в БД:
Единственное подозрение падает на загружаемые blob-ы.
Делаю так:


Потом callStms.addBatch(); + callStms.execBatch();
Но при этом я же не освобождаю buff,
т.е. не делаю ни
buff.freeTemporary();
ни
buff.close();
ни
buff.free();
(что именно из этого нужно пока тоже не в курсе)
И еще есть подозрение, что "освобождать" надо после execBatch.
То есть придется собирать все эти локаторы в коллекцию и потом циклом проходить чистить?