Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Регулярное падение производительности  [new]
VZ
Member

Откуда: Питер
Сообщений: 60
Привет. Ситуация такая: каждый понедельник отчет, который запускается ежедневно, вешает всю систему и работает жутко медленно. В остальные дни все ОК. Никаких заданий на понедельник не стоит. Никакой экстра активности пользователей тоже нет. Все задания по обновлению индексов и статистик запускаются в выходные и судя по истории благополучно успевают завершиться задолго до утра понедельника. Нагрузка на сервак приходится на память и т.к. последней маловато, то и соответственно на дисковую подсистему, хотя pagefile используется проц. на 30-40. Если отчет вырубить - все приходит в норму.

Есть-ли какие-нибудиь идеи, как отследить процесс в SQL сервере (например с помощью профайлера), который конфликтует с этим отчетом. Что вообще может происходить?
1 ноя 04, 17:16    [1075895]     Ответить | Цитировать Сообщить модератору
 Re: Регулярное падение производительности  [new]
Breakneck
Member

Откуда: Kiev
Сообщений: 2454
1. В процессе выполнения проконтролировать с помощью процедур sp_who и sp_lock наличие блокировок.
2. В процессе выполнения проконтролировать с помощью системных счетчиков узкие места сервера.
3. Проанализировать план выполнения запроса для построения, полученный из профайлера, и попытаться его оптимизировать.
1 ноя 04, 17:27    [1075936]     Ответить | Цитировать Сообщить модератору
 Re: Регулярное падение производительности  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2676
Я бы первым делом подозревал еженедельные процессы, которые зашедулены на выходные.
1 ноя 04, 17:30    [1075942]     Ответить | Цитировать Сообщить модератору
 Re: Регулярное падение производительности  [new]
VZ
Member

Откуда: Питер
Сообщений: 60
Узкие места я описал. Отчет работает не на основе запроса, а на основе очень кривого алгоритма, который нельзя оптимизировать. Но в другие дни и этот алгоритм работает приемлимо. Блокировки... надо посмотреть, но судя по Current Activity нет.

P.S. Эта с**а дождалась конца рабочего дня и теперь летает. :(
1 ноя 04, 17:30    [1075946]     Ответить | Цитировать Сообщить модератору
 Re: Регулярное падение производительности  [new]
VZ
Member

Откуда: Питер
Сообщений: 60
Задания запланированные на выходные я проверял, судя по хистори они успешно заканчиваются задолго до начала запуска отчета. Правда не знаю можно-ли этому верить, самое большое задание это Reorganize data & index pages для двух баз общим размером 15,5 Gb и общим кол-вом таблиц 2300, выполняется за всего за 2-3 часа. Так... Ага, вот какая-то фигня в наличии, на задание Rebuild Indexes для самой большой базы ушло, как показывает хистори... 5820 часов, при том, что начало 31.10.04 23:04:53, а конец 01.11.04 0:42:00. Опять непонятно. Если считать верными даты начала и конца выполнения задания, то оно заканчивается задолго до 10:05 (время запуска отчета). А если верить длительности, то оно почти год выполнялось. Чему верить? Как можно отследить подобную активность сервера, по каким событиям? Может вообще отказаться от перестройки индексов? А что даст обновление статистики взамен? Вопосов куча.
2 ноя 04, 10:49    [1077013]     Ответить | Цитировать Сообщить модератору
 Re: Регулярное падение производительности  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2676
VZ
А если верить длительности, то оно почти год выполнялось.

Врет.
VZ
Может вообще отказаться от перестройки индексов? А что даст обновление статистики взамен?

Это надо делать не взамен, а вместе.
Обновить индексы, потом статистику.
Можно это делать например скриптом:
declare @nm varchar(1000)
declare STAT_Cursor cursor for select '['+db_name()+']..['+name+']' 
from sysobjects where xtype = 'U' and name <> 'dtproperties' order by name for read only
open STAT_Cursor 
fetch next from STAT_Cursor into @nm
while @@fetch_status = 0 begin
  exec('DBCC DBREINDEX ('''+@nm+''')')
  exec('update statistics '+@nm+' with fullscan, all')
  fetch next from STAT_Cursor into @nm
end 
close STAT_Cursor
deallocate STAT_Cursor

когда я говорил про еженедельные процессы, я подразумевал главным образом не реорганизацию данных, а какие-то расчеты, производимые скриптами.
У нас например по ночам сервер пересчитывает фин. аналитику.
И что он там считает, куда и как кладет результаты - админам слабо известно. :))
2 ноя 04, 11:00    [1077081]     Ответить | Цитировать Сообщить модератору
 Re: Регулярное падение производительности  [new]
Sergey_SK
Member

Откуда:
Сообщений: 120
Обрати внимание на работу MSSQL c памятью.
Наблюдалась аналогичная ситуация, по понедельникам все сидят в самом начале курят, ждут.
дело поправилось настройками SQL:
выделеним не с 0 а с метров 50 + Резервирование памяти.
2 ноя 04, 12:26    [1077431]     Ответить | Цитировать Сообщить модератору
 Re: Регулярное падение производительности  [new]
VZ
Member

Откуда: Питер
Сообщений: 60
Я честно говоря, как-то не очень горю желанием сам скрипты писать для maintenance, для этого стандартные средства есть типа Maintenance Plan. А вот там либо Reorganize data & index pages, либо Update the statistics used by the query optimizer. Почему?

Нет, сервак в выходные не должен ничего считать.

Так верить тому, что весь maintenance заканчивается раньше? Если да, то как отловить процесс, который мешает жить? Какие события мониторить?
2 ноя 04, 12:40    [1077512]     Ответить | Цитировать Сообщить модератору
 Re: Регулярное падение производительности  [new]
Glory
Member

Откуда:
Сообщений: 104760
Так верить тому, что весь maintenance заканчивается раньше? Если да, то как отловить процесс, который мешает жить? Какие события мониторить?
Брать в руки Profiler и Performance Monitor и выяснять
- какие события вообще происходят на сервере
- что именно в процедуре отчета выпоняется медленно
- какие ресурсы при этом используются
- какие блокировки накладываются
2 ноя 04, 12:54    [1077581]     Ответить | Цитировать Сообщить модератору
 Re: Регулярное падение производительности  [new]
KOLCHOZ_POSTEVENT
Guest
Спроси сетевиков,можа,они антивирус по всей сети распространияют,сервер рад бы ответить ,а не может.
2 ноя 04, 13:11    [1077661]     Ответить | Цитировать Сообщить модератору
 Re: Регулярное падение производительности  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2676
VZ
каждый понедельник отчет, который запускается ежедневно, вешает всю систему и работает жутко медленно.


Наш ответ Чемберлену:
Запускать отчет в понедельник в 1 час ночи.
Чтобы к началу рабочего дня все устаканилось.
2 ноя 04, 13:24    [1077731]     Ответить | Цитировать Сообщить модератору
 Re: Регулярное падение производительности  [new]
VZ
Member

Откуда: Питер
Сообщений: 60
Sergey_SK
Обрати внимание на работу MSSQL c памятью.
Наблюдалась аналогичная ситуация, по понедельникам все сидят в самом начале курят, ждут.
дело поправилось настройками SQL:
выделеним не с 0 а с метров 50 + Резервирование памяти.


А в чем фишка? Про резервирование понятно, но тут правда в принципе памяти маловато, а добавить пока никак, так что все равно свопать будет, а что даст настройка выделения памяти начиная с 50 Mb?

Glory
Брать в руки Profiler и Performance Monitor и выяснять
- какие события вообще происходят на сервере
- что именно в процедуре отчета выпоняется медленно
- какие ресурсы при этом используются
- какие блокировки накладываются


Я к сожалению не дока в profiler. :( Сидел вчера мониторил всеь день, ну вижу что куча пользователей работает, кто-то больше, кто-то меньше, но как понять кто из них может так конфликтовать с этим отчетом и именно по понедельникам? Единственное, что я точно знаю, так это то, какие таблицы используются в работе отчета. Из Performance Monitor видно, что интенсивный пайджинг идет, ну понятно, что памяти не хватает.
2 ноя 04, 14:22    [1077960]     Ответить | Цитировать Сообщить модератору
 Re: Регулярное падение производительности  [new]
Glory
Member

Откуда:
Сообщений: 104760
но как понять кто из них может так конфликтовать с этим отчетом и именно по понедельникам?
Ну так наверное нужно запустить трассировку в понедельник. Чуть раньше начала работы отчета.
2 ноя 04, 14:24    [1077969]     Ответить | Цитировать Сообщить модератору
 Re: Регулярное падение производительности  [new]
VZ
Member

Откуда: Питер
Сообщений: 60
Glory
но как понять кто из них может так конфликтовать с этим отчетом и именно по понедельникам?
Ну так наверное нужно запустить трассировку в понедельник. Чуть раньше начала работы отчета.


Ну так вчера как раз и был понедельник :)
Я с утра, как пришел, так сразу за трассировку. Но народ в это время уже фигачит вовсю. Вот сейчас, например, я запустил этот отчет ради теста. и поставил трассировку на события типа Locks? это кроме стандартных. Но их офигенная куча происходит, как их отбирать? По длительности?
2 ноя 04, 14:33    [1077988]     Ответить | Цитировать Сообщить модератору
 Re: Регулярное падение производительности  [new]
Glory
Member

Откуда:
Сообщений: 104760
Вот сейчас, например, я запустил этот отчет ради теста. и поставил трассировку на события типа Locks? это кроме стандартных.
Для начала нужно было поставить трассировку выполнения отдельных команд отчета. И выяснить их продолжительность и нагрузку которые они дают.
После этого выяснить то же самое но уже при "нормальной" работе отчета.
Заодно сравнить счетчики производительности для этих двух "режимов"(загрузку процессора, очередь к диску и тп)

После этого приступить к анализу команд отчета которые в двух разных случаях работают по разному.
2 ноя 04, 14:38    [1078001]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить