Добрый день!

Есть приложение написанное на Java 7, которое использует через JDBC (Jaybird 2.2) Firebird 2.5 в качестве БД в режиме Embedded Server. Приложение выполняет разбор и анализ реестров на основе классификаторов. Эти классификаторы имеют объем порядка 25 млн записей. Приложение при запуске проверяет наличие данных в классификаторах и если они отсутствуют, то перед началом разбора реестров происходит загрузка классификаторов с фиксацией через каждые 3000 записей.

Есть контрольный реестр для разбора и анализа с использованием этих классификаторов. Проблема в том, что если разбор и анализ реестра производился в рамках той же JVM (загрузка классификаторов в отдельном коннекте/ах к БД не изменяют картины), в которой происходила загрузка классификаторов, то при анализе реестров скорость работы запросов к БД к таблицам, хранящим данные классификаторов, снижается в несколько ДЕСЯТКОВ раз по сравнению со случаем, когда загрузка классификаторов производилась заранее (например при предыдущем запуске приложения).

Может у кого-нибудь есть мысли из-за чего может возникать такое падение производительности?

hvladЕсли действительно для нормальной производительности требуется рестарт приложения, то
- возможно проблемы (с памятью ?) у JVM после анализа реестров ?
Мониторинг и анализ Heap Space не показывают рост использования памяти или большого количества каких-то не базовых java-классов. Загрузка классификатора (25 млн строк) идет около 45 минут и если бы была утечка памяти (или незакрытые препарированные запросы), то мы скорее всего смогли бы зафиксировать это.

Есть еще один момент о котором я не упомянул в своем первом посте. В момент загрузки классификаторов мы удаляем индексы и после окончания загрузки их заново создаем. Но при повторном запуске приложение анализирует наличие данных в классификаторе и повторно не загружает данные и соответственно не пересоздает индексы. Может у FB (или JDBC-драйвера) переполняются какие-то внутренние структуры, что мешает после только что выполненного создания индекса их правильно использовать (наличие статистики или еще что-то)?

И еще один уточняющий момент

hvladСимонов Дениспервый мой вывод основан вот на этом http://www.sql.ru/forum/697278-1/fetch-v-embedded-v-razy-medlenney-chem-v-ss С чего ты взял, что у автора проблемы с фетчем ?


Проблем с fetch на мой взгляд быть не должно потому, что ResultSet почти у всех запросов составляет не более 2-3 записей. И основная задержка именно при выполнении запроса (excecuteQuery), а не при fetch

Dimitry SibiryakovpalsМожет у кого-нибудь есть мысли из-за чего может возникать такое падение производительности?

Это Ява. Следовательно - сборка мусора.


А что именно в сборке мусора может быть не так? На что вы предлагаете обратить внмание? Профилирование JVM не показывает ни утечек памяти ни увеличения времени запуска GC ни учащения запуска GC.

Dimitry SibiryakovpalsА что именно в сборке мусора может быть не так?

Она просто не может не запуститься после того, как по памяти прогонят 25 миллионов объектов.


Конечно GC запускается за время загрузки. Размер кучи установлен достаточно большой (1ГБ). Точное количество запусков Eden GC и Full GC я могу привести тоже, но не думаю, что это поможет в поиске проблемы.

Мне кажется, что проблема либо на стороне FB, либо на стороне JDBC-драйвера. Как я уже говорил после загрузки данных мы заново создаем индексы (ранее удаленные перед началом загрузки). Возможно FB не успевает собрать статистику или заполнить какие-то свои внутренние структуры для полноценного использования индексов, а может есть какие-то особенности работы FB с индексами в режиме Embedded Server?