Ребята, задача заключается в следующем:

Надо в БД сохранить 800000 объектов.

Интересное начинается после 200000 объектов, жёсткий диск крутится без перерыву, нагрузка на процессор нулевая. до этого(до 200000) нагрузка на процессор была 100%.

После некоторого времени, жёсткий диск останавливается(почти останавливается),  и нагрузка на процессор опять 100% и потом опять падает и так продолжается и продолжается.

Производительность падает в разы. вопрос что же это за хрень такая? Может кто-то с подобным сталкивался?

Сохранение выполняется одной транзакцией или операция на несколько разбита?

одной

Когда ты выполняешь операции изменения записей, СУБД накапливает эти изменения в памяти (ей ведь надо либо зафиксировать все сразу либо откатить). Отсюда и своп. Разбей операцию на несколько транзакций.

Спасибо но проблема ещё вот в чём

у меня перед каждой вставкой идйт обращение к базе с выборкой,

вот так выглядит код





то есть перед каждой вставкой, он проверяет существует ли такая запись или нет.





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

Что посоветуете по этому поводу?

Это сообщение отредактировал(а) unkis - 3.5.2007, 13:02

Это, извиняюсь, как? Ты попросил MySQL вернуть запись с нужным первичным ключом, а она не поняла и решила что-то там сохранить? Это что за искусственный интеллект? Чего это MySQL тебя не слушается? Выбрось такую СУБД.


Каждый из 800000 объектов ты пытаешься получить из базы. Видимо таких объектов в базе довольно много. Каждый из них хранится в кэше сессии. Вот тебе еще одна причина расходования памяти. Возможны следующие пути решения:

• разбиение одной транзакции на несколько. Я уже предлагал, видимо тебя по каким-то причинам не устраивает
• проверять существует ли объект в базе используя select count(*) from ..., если существует, тогда создавать объект и сохранять, если нет, то выполнять update ...

И прочитай внимательнее в документации к Hibernate раздел "Batch processing".

Да нет она слушается, просто для неё наверно выборка длится слишком долго, так как если отключить проверку и ещё кое где поменять то процесс идёт очень быстро, но мне нужна такая проверка.





в этом была проблема, я отключил кэш, и каждые 5000 делаю 





пробывал, писал каждые 5000

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





1) а как я могу при помощи count(*) проверить существует ли объект, если он только считает.
2) и второе даже если он существует, то мне его надо вытащить и присвоить промежуточной таблицы и сохранить.
3) и почему entityManager.find(Location.class,location1.getLocation().getLocation_id()); не подходит?




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

Если до одного посчитает, значит существует. Хайтек такой.


Как я вижу из кода, тебе нужно только одно поле изменить, зачем тебе весь объект?


Потому и не подходит, что грузит весь объект в память. Зачем это нужно если можно только обновить поле, не тратя память совсем.

да только мне не нужно, не обновлять поле, а нужно вставить новый объект, ссылающийся не на новый объект, а на уже имеющийся в БД

Если у тебя связь между объектами lazy, то тогда можно давать в качестве аргумента не полный объект location, а пустой, у которого установлен тольео первичный ключ - можно создать конструктор для Location с одним аргументом.

И тогда установка location можно прописать вот так

location1.setLocation(new Location(location1.getLocation().getLocation_id());

Это конечно просто набросок - посмотри сам внимательнее.

Сейчас не могу попробывать, попробую вечером.

А вы бы не могли мне объяснить за что отвечает атрибут lazy?