|
Низкая производительность SQL 7.0 оносительно 6.5
|
|||
---|---|---|---|
#18+
При переходе с 6.5 на 7.0 прогнали тест на одинаковых базах на одном и том же железе (2хРIII, 512RAM, RAID 5). Тест вызывает статическую процедуру на Insert 1 записи, по этому Insert хлопает триггер и пускает пару статических процедур на Update других записей в др. таблицах. И это все в цикле (200). 6.5 выполняет тест быстрее, чем 7.0 в 4 - 5 раз вне зависимости от внешних условий. Нормально ли это? Есть ли какие установки, которые можно покрутить? И что можно сказать про производительность SQL 2000? Спасибо за совет, Сергей ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2000, 14:01 |
|
Низкая производительность SQL 7.0 оносительно 6.5
|
|||
---|---|---|---|
#18+
Странное дело. А вообще оптимизировали индексы на таблицах или нет? (По-моему лучшее что можно покрутить это сами запросы и таблицы) ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2000, 20:50 |
|
Низкая производительность SQL 7.0 оносительно 6.5
|
|||
---|---|---|---|
#18+
Действительно странно. Можно ему кол-во используемой памяти увеличить, а так основные настройки sp_configure он должен был взять при миграции с SQL 6.5. Статистику нужно в базе обновить, а то может действительно после миграции оптимизатор не знает какие индексы когда использовать. А вообще у нас такое наблюдение было, что после миграции скорость SELECT-ов осталась примерно на прежнем уровне, а скорость INSERT, UPDDATE и DELETE увеличилась. Я в конференции где-то видел, что народ жаловался на SP2 к MS SQL Server 7.0. Дескать, поставили его и скорость сразу замедлилась. Но сам я побоялся этот эсперимент провести, у меня стоит SP1. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.12.2000, 12:58 |
|
Низкая производительность SQL 7.0 оносительно 6.5
|
|||
---|---|---|---|
#18+
Если база данных только что создана с параметрами создания по умолчанию (1 Мб и Автоувеличение на 10%), то, возможно, что при выполнении в цикле тестовых операций производилось автоматическое изменение размеров файлов базы данных - а это весьма дорогостоящие операции. Чтобы этот фактор не влиял, нужно размер базы данных и журнала транзакций задать заведомо большим. Проверить, совпадают ли в разных версиях значения параметров настройки. В частности, Nested Triggers. Возможно, что триггеры приводили в одном случае к рекурентому запуску самих себя, в другом случае нет. Наиболее чистый эксперимент будет в том случае, если клиентское приложение расположено на другом компьютере, а на серваке ничего кроме MS SQL Server не стоит. Версия 6.5 использует фиксированные настройки памяти, а 7.0 динамически перестраивает используемую сервером память в зависимости от того, насколько интенсивно ее используют на этом же компьютере другие приложения. На перестройку параметров тоже уходит приличное время. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.12.2000, 18:29 |
|
Низкая производительность SQL 7.0 оносительно 6.5
|
|||
---|---|---|---|
#18+
А выполнялся ли переход с 6.5 на 7.0 по схеме с 2-мя компьютерами? Если нет, то такая ситуация совершенна не удивительна, Майкрософт проблему замедления при апгрейде официально признает, но в чем дело не говорит. 7.0 должен ставиться на совершенно чистую машину, на которой НИКОГДА не стоял 6.5, а если и был, то компу надо сделать "Формат Цеце" и поставить все заново. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.12.2000, 16:02 |
|
|
start [/forum/topic.php?fid=46&msg=32001253&tid=1827523]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
38ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
others: | 17ms |
total: | 144ms |
0 / 0 |