Добрый день.
Заметили постоянную нагрузку в tempdb. Приложил скриншоты.
Есть два графика в графане по дисковым операциям.
Один 7 дней назад, когда сервер был 2014 и один на сегодня когда он уже стал 2017.
Видно что нагрузка в 2017 почти константа. Постоянно ровная, в то время как в 2014 прыгала.
Как можно определить, что постоянно пишет и читает в tempdb с завидным постоянством.
Активных прямых реквестов в tempdb нет.

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

Версия сервера 14.0.3049.1
Allow Snapshot Isolation = False

aleks222В tempdb создают временные таблицы и обычные запросы, если сервер счел это нужным.

Поэтому, вы наблюдаете нормальную работу сервера.
Продолжайте наблюдение...
Есть 3 идентичных контура с одинаковым Application слоем.
Два контура перевели на 2017, один остался на 2014.
В контуре на 2014 в Activity Monitor по иопсам в tempdb штиль в любое время суток.
В контурах переведенных на 2017 в Activity Monitor по иопсам в tempdb то что видите.

В ближайшее время оставшийся контур с 2014 тоже обновится на 2017, тогда и увидим, дело в обновлении или нет.

Тем более я понимаю если бы IO прыгало.. Ведь нагрузка не может быть равномерной...
А тут стабильно почти равно (чтение = записи) при чем 10-15 и так пару дней. Заббикс снимает IO каждые пару секунд. Как будто что-то бесконечно пишет/читает одно и тоже.

Yasha123ну или если это днем и постоянно, сами периодически запускайте и смотрите
24х7 это
Из нюансов, что на 2014 контуре, что на 2017 контуре:
1) Настроен Always On. Это Primary нода.
2) Это издатель в репликациях транзакциями (но не распространитель).

Пока единственное на что грешим, это изменился алгоритм Always On и он начал юзать tempdb. Но это надо доказать еще.
Yasha123sys.dm_db_task_space_usage в помощь.
Попробуем, спасибо.

aleks222X-Citeпропущено...

Есть 3 идентичных контура с одинаковым Application слоем.
Два контура перевели на 2017, один остался на 2014.
В контуре на 2014 в Activity Monitor по иопсам в tempdb штиль в любое время суток.
В контурах переведенных на 2017 в Activity Monitor по иопсам в tempdb то что видите.


Вы противоречите собственным картинкам.

Там ЦИФИРЬКИ в правом нижнем углу отличаются нинасколько.
Картинка это один контур №2 когда был 2014 (нделю назад) и стал 2017.
Контур №1 до сих пор на 2014 и там штиль.
Контур №3 сейчас 2017 и та же борода, что и с контуром №2
Может быть на контурах №2 и №3 нагрузка была всегда, просто не обращали внимания.
Но в данный момент интересует что может с завидным постоянством считайте каждую наносекунду 24х7 вызывать чтение/запись в одинаковых цифрах.

TaPaKX-Cite,

а если график закрутить до 100Gb то штиль будет везеде

А если так?

Интервал обновления монитора 1 секунда. Цифры чтения/записи почти всегда равны и меняются незначительно.

Вопрос не в том, что есть нагрузка.. а в том что раньше она хоть немного прыгала. А сейчас ровная как забор. Ну и да, попутно понять что пишет/читает.

Yasha123картинки штамповать видимо приятнее, чем 2 строки кода написать.
тогда уж присоединяюсь к алексу, "Продолжайте наблюдение".
рисуйте больше, красьте пожирнее
Все спасибо. Нашли вредителя. В контуре №1 и №3 этот же запрос не нагружает tempdb. Разница в качестве данных. Будем разбираться с контуром №2.

Andy_OLAPX-Citeпропущено...

Все спасибо. Нашли вредителя.
Вредитель - использование merge join с сортировкой внутри tempdb. Потому что на 2014-м активно использовался hash join, а в 2016/2017 оценка использования оперативной памяти поменялась, и Вы получили то, что получили.
Зато нагрузка на CPU немного упала, ведь так?
Прелесть в том что там нет JOIN. Microsoft Dynamics Navision их не умеет делать просто. Он все обрабатывает только простыми селектами и курсорами.

Обычный селект с фильтрацией и сортировкой.

По плану оператор sort получился.
Operator used tempdb to spill data during execution with spill level 2 and 1 spilled thread(s); Sort wrote 6776 pages to and read 6776 pages from tempdb with granted memory 976KB and used memory 976KB

На вход в оператор 17к записей с эстимейтом в 23 записи.

По итогу оказалось что версия MSSQL никакого отношения не имеет. Либо реально изменилась оценка выделения памяти и на 17 памяти под сортировку не стало хватить и он сбрасывал в tempdb ее. А запрос этот выполняется непрерывно бесконечно. По сути разбор очереди с правилами.

Просто совпало то, что обновили и обратили внимание на графики.

Дело было в запросе и оценке. Положили индекс, чтобы избавится от сортировки и IO tempdb упало до 0.

Было Row/Row

TaPaKX-CiteБыло Row/Row
ну на 2014 другого и не должно быть :)
Нет...
Row/Row это было до накатки индекса на 2017.

После накатки индекса уже не смотрел, некогда. Не моя зона ответственности, я просто помогал им. :)