1Сv8 + SQL 2005 - помогите найти причину "тормозов"
Модераторы: Trinity admin`s, Free-lance moderator`s
1Сv8 + SQL 2005 - помогите найти причину "тормозов"
Доброе время суток, господа!
Помогите, плиз, порешать проблему.
Имеем:
1. Сервер 2хXeon 3Гц HT включен, 4Гб RAM, 4 SCSI 10k rpm в RAID10 на контроллере Adaptec SLP-2130
2. Windows 2003 Server SP1, SQL Server 2005 SP1, 1С:Предпирятие 8.0 Сервер предприятия (16-й релиз)
3. База с данными 1С ~20 Гб в Simple mode
При выполнении локально на сервере "тяжелых" операций, например, при массовом перепроведении
документов, наблюдаю "недогруженность" процессоров:
Средний % загруженности процессоров: 25-30
Диски "отдыхают" : 3 - 15 обращений / сек
SQL Server\Buffer cache hit ratio > 99 %
При этом счетчики
Поставлено в очередь DPC при среднеим значении 80 может достигать максимума 2300
Ошибок страницы/сек (Memory\Page Faults/sec) при среднем значении 350 могут достигать максимума в 2000-2500
Показатель Page Faults/sec для процесса dllhost#1 (Сервер Предприятия) составляет 205 и 500 соответственно
Вопрос.
В чем м.б. причина тормозов?
Куда смотреть, что нужно донастроить в параметрах?
Спасибо за внимание.
Помогите, плиз, порешать проблему.
Имеем:
1. Сервер 2хXeon 3Гц HT включен, 4Гб RAM, 4 SCSI 10k rpm в RAID10 на контроллере Adaptec SLP-2130
2. Windows 2003 Server SP1, SQL Server 2005 SP1, 1С:Предпирятие 8.0 Сервер предприятия (16-й релиз)
3. База с данными 1С ~20 Гб в Simple mode
При выполнении локально на сервере "тяжелых" операций, например, при массовом перепроведении
документов, наблюдаю "недогруженность" процессоров:
Средний % загруженности процессоров: 25-30
Диски "отдыхают" : 3 - 15 обращений / сек
SQL Server\Buffer cache hit ratio > 99 %
При этом счетчики
Поставлено в очередь DPC при среднеим значении 80 может достигать максимума 2300
Ошибок страницы/сек (Memory\Page Faults/sec) при среднем значении 350 могут достигать максимума в 2000-2500
Показатель Page Faults/sec для процесса dllhost#1 (Сервер Предприятия) составляет 205 и 500 соответственно
Вопрос.
В чем м.б. причина тормозов?
Куда смотреть, что нужно донастроить в параметрах?
Спасибо за внимание.
-
- Junior member
- Сообщения: 1
- Зарегистрирован: 16 ноя 2006, 13:52
- Контактная информация:
Re: 1Сv8 + SQL 2005 - помогите найти причину "тормозов&
Возможно надо почистить таблицы итогов базы SQL от пустых записей.
У меня было 10 500 тыс записей пустых из 10 600 тыс в нескольких таблицах. После чистки база уменьшилась с 25 до 15 Гб. И все стало летать.
Для этого есть обработка , а это как ее юзать:
1. Зайти в базу на том сервере, где установлен сам SQL Server. Это важное ограничение. Если нет инсталляции клиента 1С - придется сделать.
2. Войти в базу.
3. Через меню "Файл - Открыть" запустить обработку.
4. Прописать строку соединения (нажать по кнопке, на первой закладке указать Microsoft OLE DB Provider for SQL Server, на второй админа SQL и саму базу, ту в которую зашли) 5. Галку для начала не ставить.
6. Нажать "Выполнить"
7. В окне сообщений 1С должен появиться TSQL-код вида:
Begin tran t1
Select Count(*) as ВзаиморасчетыСКонтрагентами from _AccumRegTotals3992 where (_Fld3990 = 0)AND (_Fld3991 = 0) ...
Select Count(*) as ЗаказыПокупателей from _AccumRegTotals4107 where
(_Fld4103 = 0)AND (_Fld4104 = 0)AND (_Fld4105 = 0) ...
Commit tran t1
8. Полученный текст скопировать в QUERY ANALYZER и выполнить.
Результат покажет сколько нулевых записей в каждой таблице итогов.
Особо обратить внимание на регистры ЗаказыПокупателей и ТоварыВРезервеНаСкладах !!! В них обычно больше всего "нулей". Посмотреть для этих таблиц общее количество записей, например запустив запрос вида:
Select Count(*) as ЗаказыПокупателей from _AccumRegTotals4107 уже без условий. Сравнить с количеством нулевых.
Сделать резервную копию базы (можно средствами SQL)!!!
Повторить пункты начиная с №5, но с установленной галкой "удаление".
Сформируется новый скрипт для "чистки" пустых записей.
Выполнение скрипта очистки выполняется не долго (1-3 минуты), но может вызывать блокировки у пользователей, поэтому лучше запускать когда нагрузка на базу не критична.
У меня было 10 500 тыс записей пустых из 10 600 тыс в нескольких таблицах. После чистки база уменьшилась с 25 до 15 Гб. И все стало летать.
Для этого есть обработка , а это как ее юзать:
1. Зайти в базу на том сервере, где установлен сам SQL Server. Это важное ограничение. Если нет инсталляции клиента 1С - придется сделать.
2. Войти в базу.
3. Через меню "Файл - Открыть" запустить обработку.
4. Прописать строку соединения (нажать по кнопке, на первой закладке указать Microsoft OLE DB Provider for SQL Server, на второй админа SQL и саму базу, ту в которую зашли) 5. Галку для начала не ставить.
6. Нажать "Выполнить"
7. В окне сообщений 1С должен появиться TSQL-код вида:
Begin tran t1
Select Count(*) as ВзаиморасчетыСКонтрагентами from _AccumRegTotals3992 where (_Fld3990 = 0)AND (_Fld3991 = 0) ...
Select Count(*) as ЗаказыПокупателей from _AccumRegTotals4107 where
(_Fld4103 = 0)AND (_Fld4104 = 0)AND (_Fld4105 = 0) ...
Commit tran t1
8. Полученный текст скопировать в QUERY ANALYZER и выполнить.
Результат покажет сколько нулевых записей в каждой таблице итогов.
Особо обратить внимание на регистры ЗаказыПокупателей и ТоварыВРезервеНаСкладах !!! В них обычно больше всего "нулей". Посмотреть для этих таблиц общее количество записей, например запустив запрос вида:
Select Count(*) as ЗаказыПокупателей from _AccumRegTotals4107 уже без условий. Сравнить с количеством нулевых.
Сделать резервную копию базы (можно средствами SQL)!!!
Повторить пункты начиная с №5, но с установленной галкой "удаление".
Сформируется новый скрипт для "чистки" пустых записей.
Выполнение скрипта очистки выполняется не долго (1-3 минуты), но может вызывать блокировки у пользователей, поэтому лучше запускать когда нагрузка на базу не критична.
2 alex_belfast
эта ошибка "старых" платформ. 16-й релиз итоги считает вроде как правильно. У нас лечилось обновлением платформы и пересчетом итогов.
Большиой размер не у данных, а у индексов регитсра бухгалтерии "Хозрасчетный". Они "весят" 6Г из 19Г базы (после шринков и прочих регламентных операций).
эта ошибка "старых" платформ. 16-й релиз итоги считает вроде как правильно. У нас лечилось обновлением платформы и пересчетом итогов.
Большиой размер не у данных, а у индексов регитсра бухгалтерии "Хозрасчетный". Они "весят" 6Г из 19Г базы (после шринков и прочих регламентных операций).
Сетевой интерфейс "отдыхает", т.к. (повторюсь) "тяжелые" операции выполняются локально на сервере и по сети в этот момент сервер никто не грузит.
Отражают ли высокие показатели счетчиков Ошибок страницы/сек (Memory\Page Faults/sec) и Поставлено в очередь DPC причину низкой загрузки процессоров или нужно анализировать какие-то ещё счетчики для локализации проблемы?
Отражают ли высокие показатели счетчиков Ошибок страницы/сек (Memory\Page Faults/sec) и Поставлено в очередь DPC причину низкой загрузки процессоров или нужно анализировать какие-то ещё счетчики для локализации проблемы?
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
А, дошло
У Вас 2 Ксеона со включенным HyperThreading, т.е. виртуальных процессора - 4 ?
Ну вот, подобные монопольные операции с БД (типа того же перепроведения документов) загружают фактически на 100% только один процессор. В связи с особенностями виндового шедулера - это выглядит как 50% нагрузки на каждый процессор при 2 или 25% - при 4 виртуальных То есть упор - именно в процессоры. В производительность каждого из, если быть точным.
У Вас 2 Ксеона со включенным HyperThreading, т.е. виртуальных процессора - 4 ?
Ну вот, подобные монопольные операции с БД (типа того же перепроведения документов) загружают фактически на 100% только один процессор. В связи с особенностями виндового шедулера - это выглядит как 50% нагрузки на каждый процессор при 2 или 25% - при 4 виртуальных То есть упор - именно в процессоры. В производительность каждого из, если быть точным.
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Равномерная загрузка процов - основная задача виндового планировщика задач. Если задача не параллелится по процессорам, шедулер ее пинает по ним по кругу, добиваясь их равномерной загрузки. Во время генерации отчетов 1С это просто наипоказательнейше.
SQL умеет параллелиться, если на него валится много запросов. Если один толстый отчет - смотря как он написан.
SQL умеет параллелиться, если на него валится много запросов. Если один толстый отчет - смотря как он написан.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 10 гостей