запрос SQL-сервера, отстающий от Java
В настоящее время мы запускаем Zing на наших больших машинах с 256 ГБ ОЗУ. Сейчас это очень ново для нас, и мы уверены, что все будет лучше.
В настоящее время наша система работает намного медленнее, чем раньше. НО это очень ранние дни, и мы уже можем сказать вам, что поддержка Zing уже доказала свою превосходность. Использование ZVision уже дает нам ключи к нашему замедлению.
Мы уже можем использовать дополнительную оперативную память, но нам нужно обновить ядро Linux, чтобы использовать более 16 ядер.
Мы получили ту же начальную медлительность при запуске RedHat Enterprise. Теперь мы запускаем KVM под сервером Ubuntu 10.04. Пока что мы не видим никакой разницы (что значительно экономит средства).
По мере того, как мы получим больше опыта на следующей неделе, я передам наши выводы.
6 ответов
Убедитесь, что ваш драйвер JDBC настроен на использование прямого подключения, а не подключения на основе ошибок. Вы можете опубликовать свой URL-адрес подключения JDBC, если не уверены.
Убедитесь, что вы используете набор результатов только для пересылки и только для чтения (это значение по умолчанию, если вы не устанавливаете его).
И убедитесь, что вы используете обновленные драйверы JDBC.
Если все это не работает, вам следует взглянуть на профилировщик sql и попытаться захватить запрос sql, когда драйвер jdbc выполняет оператор, и запустить этот оператор в студии управления и посмотрите, есть ли разница.
Кроме того, поскольку вы извлекаете так много данных, вам следует попытаться убедиться, что у вас нет замедления памяти / сборки мусора на JVM (хотя в данном случае это не так. действительно объясняют несоответствие времени).
Требуется ли столько же времени с SQLWB? Если версия Java намного медленнее, то я бы проверил пару вещей:
- Лучшая производительность достигается с помощью ResultSet, доступного только для пересылки и только для чтения.
- Я помню, что старые драйверы JDBC от MSFT были медленный. Убедитесь, что вы используете самую последнюю версию. Я думаю, что есть один общий SQL Server и один специально для SQL 2005.
Чтобы начать отладку, было бы хорошо определить, находится ли проблемная область в базе данных или в приложении. Вы пробовали изменить запрос так, чтобы он возвращал гораздо меньший результат? Если это не вернется, я бы предложил настроить таргетинг на способ доступа к БД из Java.
Попробуйте настроить размер выборки для утверждения и попробуйте selectMethod of cursor
http://technet.microsoft.com/en-us/library/aa342344 (SQL.90) .aspx
У нас были проблемы с большими наборами результатов с использованием mysql, и нам нужно было заставить его передавать набор результатов, как описано в следующей ссылке.
http://helpdesk.objects.com.au/java/avoiding-outofmemoryerror-with -mysql-jdbc-driver
Восстановление такого количества данных потребует много времени. Вероятно, вам следует найти способ не требовать от вашего приложения такого количества данных в любой момент времени. Выполните страницу с данными или используйте, например, отложенную загрузку . Без более подробной информации о том, чего вы пытаетесь достичь, трудно сказать.
Тот факт, что он выполняется быстро при запуске из Management Studio, может быть связан с неправильно кэшированным планом запроса и устаревшими индексами (скажем, из-за большого импорта или удаления). Быстро ли он возвращает все 750K записей в SSMS?
Попробуйте перестроить индексы (или, если это займет слишком много времени, обновите статистику); и, возможно, очистить кеш процедур (будьте осторожны, если это производственная система ...): DBCC FREEPROCCACHE