Проблемы с быстродействием Галактики 7.12 MS SQL

[WiRuc]

Приведите показания следующих счетчиков:

Buffer cache hit ratio %
Page reads/sec
Page writes/sec
Cache hit ratio %
Log bytes flushed/sec
Log flush wait time
Log flush waits/sec
Log flushes/sec
Average Latch Wait Time
Latch Waits/sec
Average Wait Time
Lock wait time
Lock waits/sec
Target Server Memory
SQL Compilations/sec
SQL Re-Compilations/sec

Лучше всего настроить Conter Logs, дать ему поработать в течении хотя-бы 15 минут, а затем остановить и переписать значения Average у каждого счетчика.

[WiRuc]

Сейчас полетят в меня помидоры...

Сносить ВСЕ и ставить заново - это не выход из положения - потому ка ВСЕ кроме Галки нормально и как следует фунциклирует. Драйвера-свежайшие, биос-такой же, все установлено. Вероятно, проблема заключается в какой-нибудь хитрой настройке винды или SQL-сервера.

Да, но Галактика не работает! И со счетчиками беда... Уже достаточно причин, что бы все переставить с нуля.
У нас работает на ура связка Win2003 Enterprise Edition SP1 + MSSQL 2000 SP4. И я что-то не припоминаю, чтобы были какие-то хитрые настройки.

Единственное, не была выполнена очистка хранимых процедур и t$hashvalues. По моему, это непринципиально.

Принципиально. Рекомендую выполнить удаление ХП и очистить xx$hashvalues.

Теперь про RAID5. Скорость чтения с RAID около 35Мб/сек, запись 20-25 (Аппаратный контроллер, 128Мб кэш, Ultra 320). Диски не нагружены. Поэтому, вопросы связанные с быстродействием дисков не рассматриваю.

Интересно, как вы определили, что диски не нагружены, если у вас не работает счетчик очереди диска? Да и приведенные вами значения потокового чтения/записи далеки от идел - у меня IDE винт быстрее работает.

По диспетчеру задач, SQL Server кушает где-то от 20 до 40% CPU, используется режим /3GB, память, выделенная под SQL=3Гб.

Много. Средняя загрузка не должна превышать 15%, если выше - нужно апгрейдить CPU.

Советы.
1) Запустить NapConf и проверить настройки NAPServer. Уровень авторизации должен быть "установка связи", протокол - TCP/IP, галка на чекбоксе "Авторизация необязательна".
2) В винде выключить настройку "Refresh NTFS Last Access". Она вроде особого влияния не оказывает, но все-таки лучше выключить.
3) Размер страйпа на RAID и размер кластера NTFS рекомендую установить равным 64Кб.
4) Cнести все лишнее с сервера, оставить только MSSQL и Галактику.
Никаких антивирусов, файерволов и т.д.
5) Проверить, что не включена фильтация IP пакетов.
Проверить, что не включено логгирование ODBC драйвера.
6) В System Properties установить "Использование процессора - службы", "Использование памяти - программы".
7) Проверить и отключить лишние службы, типа Microsoft Search, QoS и т.д.
В настройках MSSQL на вкладке Processor пометить все доступные CPU, Windows fiber выключить. В секции Parallelism установить Use 1 processor.
9) В настройках БД для файлов БД задать заведомо большое значение, чтобы исключить увеличение размера БД в процессе работы. На вкладке Options поставить галку на "Auto create statistics", все остальные галки убрать. Recovery model = FULL, Database compatibility level = 80.
10) Провести обслуживание БД. Т.е. перестройка всех индексов, затем выполнить DBCC SHRINKDATABASE (имя_бд, 0, NOTRUNCATE). После этого перезагрузить сервер.

[kubik]

Да, но Галактика не работает! И со счетчиками беда... Уже достаточно причин, что бы все переставить с нуля.
У нас работает на ура связка Win2003 Enterprise Edition SP1 + MSSQL 2000 SP4. И я что-то не припоминаю, чтобы были какие-то хитрые настройки.

Я очень надеюсь, что хитрые настройки здесь не при чем. Раз у вас все работает, то и у нас все должно быть ОК. А счетчики можно и вручную восстановить - есть уже практика.

Единственное, не была выполнена очистка хранимых процедур и t$hashvalues. По моему, это непринципиально.

Принципиально. Рекомендую выполнить удаление ХП и очистить xx$hashvalues.

Сделаю. Как я понимаю, надо перед этим отключить полльзователей и остановить NapSrv? Т.к., как я понял по profiler'у именно он и создает эти ХП. И объясните пожалуйста в чем тут принципиальность

Теперь про RAID5. Скорость чтения с RAID около 35Мб/сек, запись 20-25 (Аппаратный контроллер, 128Мб кэш, Ultra 320). Диски не нагружены. Поэтому, вопросы связанные с быстродействием дисков не рассматриваю.

Интересно, как вы определили, что диски не нагружены, если у вас не работает счетчик очереди диска? Да и приведенные вами значения потокового чтения/записи далеки от идел - у меня IDE винт быстрее работает.

Очень просто: копированием в nul (скорость чтения), и копированием с диска на диск. Получил практически максимальную скорость записи-чтения для данного массива. Про IDE я тут и не говорил. SCSI Ultra 320 Dual Channel c Zero Channel Raid контроллером. На одном канале - система, на другом - база.

По диспетчеру задач, SQL Server кушает где-то от 20 до 40% CPU, используется режим /3GB, память, выделенная под SQL=3Гб.

Много. Средняя загрузка не должна превышать 15%, если выше - нужно апгрейдить CPU.

Куда ж еще их апгрейдить?
2 шт Xeon 3,06 ГГц на шине 800 МГц!
А такая загрузка из-за того что у SQL сервера приоритет высокий установлен. Сорри, я об этом не сказал.

Советы.
1) Запустить NapConf и проверить настройки NAPServer. Уровень авторизации должен быть "установка связи", протокол - TCP/IP, галка на чекбоксе "Авторизация необязательна".

У нас уровень авторизации=авторизации нет. Остальное - так же.

2) В винде выключить настройку "Refresh NTFS Last Access". Она вроде особого влияния не оказывает, но все-таки лучше выключить.

Знаю я про нее. Но это ж все таки сервер. Оставим на потом.

3) Размер страйпа на RAID и размер кластера NTFS рекомендую установить равным 64Кб.

Так и есть.

4) Cнести все лишнее с сервера, оставить только MSSQL и Галактику.
Никаких антивирусов, файерволов и т.д.

Так и есть.

5) Проверить, что не включена фильтация IP пакетов.
Проверить, что не включено логгирование ODBC драйвера.
6) В System Properties установить "Использование процессора - службы", "Использование памяти - программы".

Так и есть.

7) Проверить и отключить лишние службы, типа Microsoft Search, QoS и т.д.

Qos нет. Search и другие службы не отнимают ни памяти ни CPU.
Лучше уж тогда снести Active Directory, но, к сожалению, это невозможно - сервер несет роль контроллера домена.

В настройках MSSQL на вкладке Processor пометить все доступные CPU, Windows fiber выключить. В секции Parallelism установить Use 1 processor.

Эти настройки мы сами сделали после непродолжительных экспериментов над ними.

9) В настройках БД для файлов БД задать заведомо большое значение, чтобы исключить увеличение размера БД в процессе работы.

От фрагментации файлов БД это все равно не спасет, а при нормальной работе диска прирост в быстродействии сомнителен.

10) Провести обслуживание БД. Т.е. перестройка всех индексов, затем выполнить DBCC SHRINKDATABASE (имя_бд, 0, NOTRUNCATE). После этого перезагрузить сервер.

Обслуживание CHECKDB(),REPAIR_REBUILD проводил.
SHRINKDATABASE - всего навсего "сжатие" базы - удаление пустого места. Лучше уж сделать реорганизацию страниц данных и индексов с резервированием свободного места.

СПАСИБО ЗА ДЕЛЬНЫЕ СОВЕТЫ!
Надеюсь, у нас все получится!

[sim]

kubik

сервер несет роль контроллера домена

это не есть хорошо

[coolibin]

Я почему про named pipes говорю - очень похожие тормоза на Г. у нас были с некоторыми отчетами в 7.12, причем большинство отчетов работало нормально.
Narconf показывал, что для подключения используется TCP/IP, а Enterprise Manager->Management->Process info у usera NT AUTHORITY SYSTEM\SYSTEM на нашей базе показывал Nimed Pipes в Network Library.

Да, и у меня аналогичная ситуация. Все настроено через TCP/IP - а реально в Process Info - Named pipes
И у этих юзеров иногда реально виснет гала.
Пересоздаю DSN (ничего вроде не меняя)- все становится нормально. Особенно этот вопрос пока не изучал - некогда было.

[WiRuc]

Сделаю. Как я понимаю, надо перед этим отключить полльзователей и остановить NapSrv? Т.к., как я понял по profiler'у именно он и создает эти ХП. И объясните пожалуйста в чем тут принципиальность

Дело в том, что часть процедур по мере изменений в коде Галактики становятся ненужными. Переход на новый сервер отличный повод для очистки

Очень просто: копированием в nul (скорость чтения), и копированием с диска на диск. Получил практически максимальную скорость записи-чтения для данного массива. Про IDE я тут и не говорил. SCSI Ultra 320 Dual Channel c Zero Channel Raid контроллером. На одном канале - система, на другом - база.

Вы таким образом меряли потоковые скорости, а СУБД работает с дисками совсем по другому сценарию. При работе MSSQL важна очередь диска, т.к. чтение/запись производится в несколько асинхронных потоков по всему диску маленькими блоками. Нужно обязательно мерить очередь диска. Кстати, приведите полную схему ваших дисковых массивов - система, системные БД, tempdb,рабочая БД с расположением отдельных файлов каждой БД.

Qos нет. Search и другие службы не отнимают ни памяти ни CPU.
Лучше уж тогда снести Active Directory, но, к сожалению, это невозможно - сервер несет роль контроллера домена.

Это не есть хорошо. Лучше разнести по отдельным серверам. У нас под Галактикой отдельный сервер, отдельно контроллер, отдельно прокси.

От фрагментации файлов БД это все равно не спасет, а при нормальной работе диска прирост в быстродействии сомнителен.

Процесс увеличения размера БД очень ресурсоемкий процесс - идет обновление служебных объектов (GAM,SGAM) + новые области заполняются нулями. Все это время большинство пользователей будет висеть на блокировках, а остальные - дико тормозить. Поэтому, я рекомендую сразу выделить много места под файлы БД.

Обслуживание CHECKDB(),REPAIR_REBUILD проводил.
SHRINKDATABASE - всего навсего "сжатие" базы - удаление пустого места. Лучше уж сделать реорганизацию страниц данных и индексов с резервированием свободного места.

Запускать CHECKDB в данной ситуации нет никакого смысла. Надо запускать DBCC DBREINDEX для всех таблиц БД. А SHRINKDATABASE с опцией NOTRUNCATE как раз и производит реорганизацию страниц данных. Кстати, если вдруг надумаете увеличить размер БД, не вздумайте запускать SHRINKDATABASE без опции NOTRUNCATE, иначе сожмете всю БД.
Хинт. Для вызова DBREINDEX для всех таблиц можно воспользоваться следующей конструкцией:

Код: Выделить всё

exec sp_MsForEachTable 'DBCC DBREINDEX ([?],'''',100) WITH NO_INFOMSGS'

[kubik]

Приведите показания следующих счетчиков:

Среднее Максимум
Buffer cache hit ratio % 99,834 99,892
Page reads/sec 6,283 27,002
Page writes/sec 28,022 1340,068
Cache hit ratio % 51,379 51,411
Log bytes flushed/sec 50985,765 2438786
Log flush wait time 47 672
Log flush waits/sec 13,950 49,998
Log flushes/sec 14,193 53,003
Average Latch Wait Time 68,964 877,044
Latch Waits/sec 42,053 3391,180
Lock wait timev 69,125 6843,347
Lock waits/sec 0,010 1,000
Target Server Memory 2691500 2691528
SQL Compilations/sec 3,192 61,003
SQL Re-Compilations/sec 0,010 1,000

[WiRuc]

1. Очень низкий Cache hit ratio, нормальным считается значение в районе 90%. Обычно это решается увеличением памяти.
О нехватке памяти говорит также высокий показатель SQL Compilations - процедурный кэш мал, поэтому он очень быстро обновляется.
2. Высокий показатель Log flush wait time. Лечится вынесением лога в отдельный массив RAD 1. Вообще-то всегда рекомендуется выносить лог отдельно от основной БД из-за того, что работа с логом обычно заключается в последовательной записи, в отличии от рандомного чтения/записи в основной БД. Если у вас контроллер с батарейкой, то поможет включение Write Back кэша на контроллере.
3. Latch wait\sec, wait Time.
Тут сложно сказать, скорей всего Latch связаны с медленной дисковой подсистемой, хотя тут нужно смотреть более детально в процессе работы.
4. Огромное значение Lock wait time. Вам нужно посмотреть с чем связаны локи. Если пользователь блокирует сам себя, то это медленная дисковая подсистема. Если несколько пользователей блокирует друг друга, то надо смотреть из-за чего это происходит, для Галактики это очень нетипично (из-за отсутствия транзакций).

Еще раз рекомендую посмотреть очереди дисков.

[kubik]

1. Очень низкий Cache hit ratio, нормальным считается значение в районе 90%. Обычно это решается увеличением памяти.
О нехватке памяти говорит также высокий показатель SQL Compilations - процедурный кэш мал, поэтому он очень быстро обновляется.

Памяти всегда не хватает. На серваке 4 Гига, 3 - под SQL. База около 20 Гигов. Чтобы памяти хватало, ее надо хотя бы 10Гб. Но что есть то есть.

2. Высокий показатель Log flush wait time. Лечится вынесением лога в отдельный массив RAD 1. Вообще-то всегда рекомендуется выносить лог отдельно от основной БД из-за того, что работа с логом обычно заключается в последовательной записи, в отличии от рандомного чтения/записи в основной БД. Если у вас контроллер с батарейкой, то поможет включение Write Back кэша на контроллере.

Собственно, контроллер без батарейки, но сервак на UPS. И контроллер позволяет и без батарейки WriteBack включить. Что я и сделал уже давно. А выносить лог, на IDE (потому как в SCSI только 5й и 1й RAID) не целесообразно. Наверное, вы имели в виду RAID0? (Stripe) а не 1й - зеркало.

3. Latch wait\sec, wait Time.
Тут сложно сказать, скорей всего Latch связаны с медленной дисковой подсистемой, хотя тут нужно смотреть более детально в процессе работы.

Дисковый массив ну никак не медленней чем был на старом сервере.

4. Огромное значение Lock wait time. Вам нужно посмотреть с чем связаны локи. Если пользователь блокирует сам себя, то это медленная дисковая подсистема. Если несколько пользователей блокирует друг друга, то надо смотреть из-за чего это происходит, для Галактики это очень нетипично (из-за отсутствия транзакций).

Еще раз рекомендую посмотреть очереди дисков.

Посмотрю, как только восстановлю счетчики...

[kubik]

Кстати, приведите полную схему ваших дисковых массивов - система, системные БД, tempdb,рабочая БД с расположением отдельных файлов каждой БД.

Ultra SCSI 320 Channel 0:
80Гб+80ГБ=RAID1=Система, pagefile, DB:master,tempdb
Ultra SCSI 320 Channel 1:
80Гб+80Гб+80Гб=RAID5=DB:рабочая база Галактики
IDE Channel 0:
250 Гб=Backups