Мониторинг MSSQL сервера (как отследить нагрузку)

Здравствуйте.

Есть серв, на 10ке, на нём стоит MS SQL с ssms. На серве 1 активная бд. (с базой работает 3 asp.net приложения).

Периодически серв проседает в производительности. Все запросы\хранимки отрабатывают с явной задержкой. Почему - не ясно.
Это не разовая задержка, это что-то что просаживает производительность и после чего вся последующая работа "замедлена". Спасает только перезагрузка серва.

Вопрос: как (какими инструментами, настройками, аналитиками и т.п.) отследить текущую производительность? Как понять корректность отработанных запросов (скорость "это норм" или "много" когда разница не совсем существенна)? (чтобы в дальнейшем на основе этой инфы искать дыры и их решение).

p.s. работы по глобальному with nolock проведены - местами стало легче, но "эта" (непонятная) проблема осталась.

0

Сообщение от DarkOrk Периодически серв проседает в производительности.

насколько периодически?
что по событиям сервера и винды?

Сообщение от DarkOrk работы по глобальному with nolock проведены

это вообще не очень правильно

0

qwertehok, каждый день. То есть, после перезагрузки (если грузанул во второй половине дня) всё норм. Утром - всё норм. В обед - смерть. Грузанул в обед и всё по кругу.

В событиях чисто (нет ошибок и предупреждений о "полной попе"). Есть информационные, но я их почитал и там нефига интересного.
Не знаю на сколько вот это важно:



Есть идеи?

p.s. по with nolock почитаю. спс.

0

Ну где же вы, великие DB DEVELOPERы?

0

может никто не хочет писать пока вы не дадите больше инфы?

нагрузку на сервер - в простое и когда "умирает"
данные по памяти, винтам, процессору

неплохо было бы профайлером подключиться и смотреть что происходит в этот момент
помониторить запросы которые выполняются

0

qwertehok, так к этому и тема. Я НЕ ЗНАЮ как это всё делать (вернее "что именно делать нужно").
Мне нужна помощь, в разборе мониторинга серва.

Память загружена на 3ть.
Проц вообще спит всегда (16 ядер, ему вообще скучно играться с нашим сервом и его задачами).
Диск (тут точно не знаю) - не видел пиковых нагрузок. В штатном режиме.
Сеть - на 10% от возможного.

По мониторингу из ssms самые больше паузы даёт Latch блокировки (ниже скрин. это "за 1 день").

Я почитал стати с msdn-а, почитал посты на хабре. Как бы ок. На первом есть варианты "куда смотреть", во втором "как решать", но и тот, и тот не даёт последовательный ответ.
Как бы, как запустить "расширенные события" или же настроить датчики мониторинга (в системном мониторинге) я понял, другой момент, я не понимаю какое значение будет говорить о том что "у нас тут полная попа" или же всё в пределах разумного исполняется.
Видел интересный вариант, на хабре, о том что план сервера строится на одних данных, по фарту, за время работы данные меняются, план становится не актуальным и серв "не правильно" работает (с точки зрения быстродействия), но, ещё раз, я новичок в этом вопросе и не понимаю "что хорошо,а что плохо" и где ЛУЧШЕ это смотреть.

Миниатюры

 

0

Здравствуйте.
Вот, удалось получить гаф статистику, с большой нагрузкой (как раз в эти моменты и "проседает").

Как эту информацию интерпретировать и как посоветуют действовать? (плз, развёрнутые комменты, как для новичков)

Миниатюры

 

0

DarkOrk, имеет место быть недостаток памяти.
В перфомансе мониторе смотрите для SQL Server значения счетчиков Target Server Memory и Total Server Memory. Они должны быть равны или незначительно отличаться.

Так же есть ожидания на блокировках. На каких и почему нужно выяснять дополнительно.
Необходимая информация есть в sys.dm_os_waiting_tasks и sys.dm_exec_requests.
Или установите sp_whoisactive

Само-собой бессмысленно что-либо анализировать вне моментов просадок.

Можете еще посмотреть подробную кумулятивную статистику ожиданий запросом вот отсюда - https://www.sqlskills.com/blog... -it-hurts/

0

invm, этот скрин (по которому вы отписались) был получен при отключении параллелизма.
При отключенном параллелизме бы такие показатели. Стабильно появились блокировки и память периодически загружала (этот скрин как раз в такой момент поймал).

При включённом - проблемы с памятью не проявлялись (совсем). К слову, даже в тот момент когда был этот показатель, диспетчер не показывал всплесков по загруженности озу (30-40% стабильно).
Скрипт (по ссылки что вы дали) я видел. При работающем параллелизме, где-то 50 на 50 забирает на себя CXPACKET и LATCH_EX. (как решение, нашёл вариант отключить параллельность, но это не вариант (почему видно на скрине выше ) ).

ЦП стабильно работает, без перегрузок.
Диск тоже, по моему, качает. Очередь не создаёт.

Сообщение от invm Само-собой бессмысленно что-либо анализировать вне моментов просадок.

Я это понимаю, но не знаю как сделать скрины\логи во время работы, не так что бы "показалось (на экране) и пропало", а что бы я это показать мог?! ...т.к. моих знаний, сейчас, не хватает чтобы самому это проанализировать, а как вы сами пишете "вне момента просадок" нефига не решить.

Кстати, о профайлере.
Может подскажите какие ивенты там настроить и на что смотреть (т.к. там действительно много всего и что именно мне надо, мне не ясно).

Ниже скрин по мониторингу при включённом параллелизме.
Как понять откуда берутся локи (на каких конкретно ресурсах и при каких запросах)?

Миниатюры

 

0

Сообщение от DarkOrk При работающем параллелизме, где-то 50 на 50 забирает на себя CXPACKET и LATCH_EX.

CXPACKET - нормальное явление при параллелизме и его можно игнорировать. Плюс наличие параллелизма, в большинстве случаев, свидельствует о кривости запросов.
Много ожиданий LATCH_EX говорит о проблемах с "писателями". Каких именно и надо выяснять.

Я не зря упоминал о sp_whoisactive. Этим средством можно анализировать ситуацию в момент "просадок" - выявлять запросы в состоянии suspended и смотреть на ожидании какого ресурса они висят.

Если версия позволяет, включите Query Store. См. в документации как этим средством выявлять деградировавшие запросы.

0

Сообщение от DarkOrk проблемы с памятью не проявлялись (совсем)

Сообщение от DarkOrk ЦП стабильно работает, без перегрузок. Диск тоже, по моему, качает. Очередь не создаёт.

значит проблем нет

0