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

Имеется простой запрос, выполняющийся несколько раз в день

Select count(*) from table where [column1] = [value1] and [column2] = [value2]

В таблице несколько сот миллионов записей, столбцы в where входят в индекс.
После выходных наблюдается рост времени выполнения этого запроса примерно в 5 раз.
Нагрузка на сервер в эти дни имхо не выросла (хотя по счетчикам не засекал) Индекс перестроил, не помогло.

Вопрос: какие физические ресурсы в принципе использует count и другие агрегатные функции? Оперативка, tempdb?
19 окт 16, 09:36    [19797898]     Ответить | Цитировать Сообщить модератору
 Re: Падение производительности  [new]
gds
Member

Откуда: Железнодорожный
Сообщений: 1842
Блог
Qwerty2016,

В выходные тоже выполняется запрос?
19 окт 16, 09:46    [19797951]     Ответить | Цитировать Сообщить модератору
 Re: Падение производительности  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31438
Qwerty2016
Вопрос: какие физические ресурсы в принципе использует count и другие агрегатные функции? Оперативка, tempdb?
Никаких, по сравнению с выполнением запроса без них. Грубо говоря, 4 байта в памяти для счётчика.

Смотрите план выполнения запроса, блокировки.
19 окт 16, 09:49    [19797968]     Ответить | Цитировать Сообщить модератору
 Re: Падение производительности  [new]
gds
Member

Откуда: Железнодорожный
Сообщений: 1842
Блог
Qwerty2016
Добрый день, коллеги!

Вопрос: какие физические ресурсы в принципе использует count и другие агрегатные функции? Оперативка, tempdb?


Оперативка, tempdb, Диски.
19 окт 16, 09:50    [19797972]     Ответить | Цитировать Сообщить модератору
 Re: Падение производительности  [new]
Qwerty2016
Guest
gds,

Диски - понятно. Оперативка и tempdb как задействованы? Там же просто сканируется поток и вычисляется кол-во строк. В памяти нужно sizeof(bigint) байт, а tempdb при чем (я ее указал в вопросе, т.к. она в выходные была перенесена на другое зеркало)?
19 окт 16, 09:59    [19798046]     Ответить | Цитировать Сообщить модератору
 Re: Падение производительности  [new]
Qwerty2016
Guest
alexeyvg,

блокировок нет, а план такого запроса вряд ли может измениться..
19 окт 16, 10:02    [19798075]     Ответить | Цитировать Сообщить модератору
 Re: Падение производительности  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
А посмотреть на чем висит в момент выполнения никак?
19 окт 16, 10:12    [19798164]     Ответить | Цитировать Сообщить модератору
 Re: Падение производительности  [new]
Qwerty2016
Guest
Mike_za
А посмотреть на чем висит в момент выполнения никак?


Так не висит, крутится. Но много дольше, чем раньше.
Я хочу вообще понять, как вообще работает.
19 окт 16, 10:25    [19798269]     Ответить | Цитировать Сообщить модератору
 Re: Падение производительности  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31438
Qwerty2016
Я хочу вообще понять, как вообще работает.
Много же причин может быть.
- Изменился план запроса.
- Изменились данные, и теперь запрос выводит в 10 раз больше строк.
- Деградировал массив, 6 рейд работает с парой отказавших дисков.
- Ушлый админ с воскресенья майнит биткойны на серверах.
- Идёт атака подбора паролей на открытый в инет сиквел.
- Кривое приложение отъело половину памяти на сервере, и теперь сиквел успешно бомбит файл подкачки виртуальной памяти.
- Изменили какие то настройки сиквела (MAXDOP, память или ещё что то)

Нужно мониторить сиквел, сохранять результаты мониторинга (в частности, счётчики), что бы было с чем сравнивать (а то предположений "вроде не изменилось" недостаточно для выводов).
И нужно анализировать текущую работу. Профайлер, счётчики, чтение лога, в том числе за предполагаемое время изменения поведения сервера.

А то странно даже, я не представляю, какой ответ вы ожидаете на вопрос "стало медленее работать. в чём дело?"... Думаете, скажут, в каком окошке мышкой галочку включить? :-)
19 окт 16, 10:50    [19798472]     Ответить | Цитировать Сообщить модератору
 Re: Падение производительности  [new]
Qwerty2016
Guest
alexeyvg, спасибо, но вопрос сформулирован в виде "как работает count" :)

Может ли замена зеркала под tempdb влиять на производительность потоковой агрегации? Вроде нет, но вдруг что-то не знаю.

Счетчики действительно не хранятся, но большой нагрузки не вижу. Указанные причины повлияли бы на все остальные запросы, чего так же нет.
19 окт 16, 11:14    [19798617]     Ответить | Цитировать Сообщить модератору
 Re: Падение производительности  [new]
aleks2
Guest
Qwerty2016
Добрый день, коллеги!

Имеется простой запрос, выполняющийся несколько раз в день

Select count(*) from table where [column1] = [value1] and [column2] = [value2]

В таблице несколько сот миллионов записей, столбцы в where входят в индекс.
После выходных наблюдается рост времени выполнения этого запроса примерно в 5 раз.
Нагрузка на сервер в эти дни имхо не выросла (хотя по счетчикам не засекал) Индекс перестроил, не помогло.

Вопрос: какие физические ресурсы в принципе использует count и другие агрегатные функции? Оперативка, tempdb?


Осподе, за что ты мучаешь сервер?
Давно бы уже индексированную вьюху сделал... и спал спокойно.
19 окт 16, 11:25    [19798695]     Ответить | Цитировать Сообщить модератору
 Re: Падение производительности  [new]
gds
Member

Откуда: Железнодорожный
Сообщений: 1842
Блог
Qwerty2016
gds,

Диски - понятно. Оперативка и tempdb как задействованы? Там же просто сканируется поток и вычисляется кол-во строк. В памяти нужно sizeof(bigint) байт, а tempdb при чем (я ее указал в вопросе, т.к. она в выходные была перенесена на другое зеркало)?

Что бы посчитать кол-во записей на странице необходимо поднять эти страницы в память - чтение с диска. После чего если страница не используется она вытесняется из буфера. Если вдруг она изменяется, то она записывается обратно на диск. Если запрос паралелится, то подсчетом занимаются несколько потоков. Которые в конце ждут всех.
19 окт 16, 11:32    [19798740]     Ответить | Цитировать Сообщить модератору
 Re: Падение производительности  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31438
Qwerty2016
alexeyvg, спасибо, но вопрос сформулирован в виде "как работает count" :)
Я уже написал. count требует просто нескольких байт памяти, по сравнению с таким же запросом без count
Добавление count к запросу может только его ускорить, но не замедлить.
Qwerty2016
Указанные причины повлияли бы на все остальные запросы, чего так же нет.
"Указанные" - какие из них? Увеличение количества обрабатываемых строк конкретно для условий этого запроса?

Ну и потом, вы же не меряли.

Может, это самый тяжёлый запрос, к тому же частый? Все запросы стали выполняться в 5 раз дольше, но для других запросов это с 1 мс стало 5 мс, а для этого с 1 с стало 5 с?
19 окт 16, 12:55    [19799327]     Ответить | Цитировать Сообщить модератору
 Re: Падение производительности  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
посмотреть план и ожидание ну просто жуть как трудно, нет жеж будем обсуждать абстрактные причины...
не буду отставать
- уборщица спёрла планку памяти
- охранник выдернул шнурок с одной из сетевых
19 окт 16, 13:00    [19799374]     Ответить | Цитировать Сообщить модератору
 Re: Падение производительности  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31438
Qwerty2016
блокировок нет, а план такого запроса вряд ли может измениться..
Непонятно, может или нет. Там [value1] - это переменные или константы? Какие индексы, статистики, типы данных, процент обрабатываемых записей? Вполне могло измениться с seek scan.

Вы бы выложили конкретный запрос и план со статистикой выполнения.

А на начальный вопрос уже ответили. Если вас интересует, не может ли использование count что то там замедлить, то ответ "нет".
19 окт 16, 13:00    [19799376]     Ответить | Цитировать Сообщить модератору
 Re: Падение производительности  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
Сервак "остывает" в выходные. Кэши сбрасывает и прочее. Или он на виртуалке и её подпирают.
19 окт 16, 13:18    [19799523]     Ответить | Цитировать Сообщить модератору
 Re: Падение производительности  [new]
Qwerty2016
Guest
alexeyvg
Qwerty2016
alexeyvg, спасибо, но вопрос сформулирован в виде "как работает count" :)
Я уже написал. count требует просто нескольких байт памяти, по сравнению с таким же запросом без count
Добавление count к запросу может только его ускорить, но не замедлить.

А как соотнести это с предыдущим мнением, что подсчет кол-ва строк потребует подьема в память всей таблицы? Таблица довольно большая.

alexeyvg
Qwerty2016
Указанные причины повлияли бы на все остальные запросы, чего так же нет.
"Указанные" - какие из них? Увеличение количества обрабатываемых строк конкретно для условий этого запроса?

Ну и потом, вы же не меряли.


Нет, в данных ничего кардинально не менялось. Дописывается около 1000 строк в день.

alexeyvg
Там [value1] - это переменные или константы?


Константы. Кластерный индекс по value1, value2, value3 (именно в этом порядке).
Плана под рукой нет, из дома теоретизирую :)
Запрос выполняется пару раз в день, т.е. не критичен.
19 окт 16, 13:35    [19799679]     Ответить | Цитировать Сообщить модератору
 Re: Падение производительности  [new]
Qwerty2016
Guest
Владислав Колосов
Сервак "остывает" в выходные. Кэши сбрасывает и прочее. Или он на виртуалке и её подпирают.


Физический сервер, кроме сиквела ничего нет
Да, в выхи выполняется перезагрузка и обслуживание (полный бэкап, перестроение статистик и индексов). Ошибок по этим джобам в понедельник не было.
19 окт 16, 13:39    [19799700]     Ответить | Цитировать Сообщить модератору
 Re: Падение производительности  [new]
PsyMisha
Member

Откуда: другая столица
Сообщений: 773
Qwerty2016,
Попробуй оценить, когда обновлялась статистика по таблицам.
И в начале запроса включи SET STATISTICS IO ON - посмотри, сколько чтений физических (с диска), сколько логических (из буфера)

Для чистоты эксперимента можешь сделать

DBCC FREEPROCCACHE
DBCC FREESESSIONCACHE
DBCC FREESYSTEMCACHE('ALL')
DBCC DROPCLEANBUFFERS
DBCC SQLPERF('sys.dm_os_wait_stats',CLEAR)

Надо сравнивать в разные дни, с разной нагрузкой. Так невозможно что-либо предположить
19 окт 16, 13:40    [19799710]     Ответить | Цитировать Сообщить модератору
 Re: Падение производительности  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
PsyMisha,

автор
Надо сравнивать в разные дни, с разной нагрузкой. Так невозможно что-либо предположить

а что делать если его уволят к третьему дню выполнения всего того что вы перечислили?
19 окт 16, 13:44    [19799737]     Ответить | Цитировать Сообщить модератору
 Re: Падение производительности  [new]
PsyMisha
Member

Откуда: другая столица
Сообщений: 773
TaPaK - а что вы так возбудились-то - договориться насчет окна, очистить кэши, объяснить, что какое-то первое время запросы будут выполняться не столь быстро, а потом ситуация стабилизируется - погонять разик в будни, пару раз в выходные, это такая офигительная проблема чтоли?)
19 окт 16, 14:24    [19799939]     Ответить | Цитировать Сообщить модератору
 Re: Падение производительности  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
PsyMisha
TaPaK - а что вы так возбудились-то - договориться насчет окна, очистить кэши, объяснить, что какое-то первое время запросы будут выполняться не столь быстро, а потом ситуация стабилизируется - погонять разик в будни, пару раз в выходные, это такая офигительная проблема чтоли?)

логично, у человека тема называется " Падение производительности " а вы ему "какое-то первое время запросы будут выполняться не столь быстро"
ну и про системы 24/7 вы наверное не слышали
19 окт 16, 14:28    [19799964]     Ответить | Цитировать Сообщить модератору
 Re: Падение производительности  [new]
Qwerty2016
Guest
TaPaK
PsyMisha
TaPaK - а что вы так возбудились-то - договориться насчет окна, очистить кэши, объяснить, что какое-то первое время запросы будут выполняться не столь быстро, а потом ситуация стабилизируется - погонять разик в будни, пару раз в выходные, это такая офигительная проблема чтоли?)

логично, у человека тема называется " Падение производительности " а вы ему "какое-то первое время запросы будут выполняться не столь быстро"
ну и про системы 24/7 вы наверное не слышали


Падение только на одном запросе, не критично. Завтра подниму бэкап на резервный, буду ставить опыты. Скорее всего, лоханулся где-то на пустом месте.
19 окт 16, 14:55    [19800123]     Ответить | Цитировать Сообщить модератору
 Re: Падение производительности  [new]
PsyMisha
Member

Откуда: другая столица
Сообщений: 773
TaPaK
ну и про системы 24/7 вы наверное не слышали

ню-ню :)

Бессмысленный срач, нет ни времени ни желания вписываться и меряться чем бы то ни было.
Если для автора проблема настолько актуальная - можно и про служебное окно с пользователями системы договориться. В ином случае - какой тогда смысл мерять кол-во физических/логических операций

Приятного дня
19 окт 16, 14:57    [19800140]     Ответить | Цитировать Сообщить модератору
 Re: Падение производительности  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31438
Qwerty2016
alexeyvg
пропущено...
Я уже написал. count требует просто нескольких байт памяти, по сравнению с таким же запросом без count
Добавление count к запросу может только его ускорить, но не замедлить.

А как соотнести это с предыдущим мнением, что подсчет кол-ва строк потребует подьема в память всей таблицы? Таблица довольно большая.

Выборка строк тоже потребует. Ну и не всей таблицы, а той части, которая находится в соотв. диапазоне кластерного инедкса.

Вот есть запрос
Select * from table where [column1] = [value1] and [column2] = [value2]

Выполняется Н секунд.
Заменили * на count(*)
Вопрос: Может запрос замедлиться?
Ответ- не может.
С чего ему замедляться то? Сколько данных выбиралось, столько и выбирается.
19 окт 16, 17:56    [19801303]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить