Коллеги, всем добрый день.

В очередной раз возникли проблемы в БД с производительностью. Не конкретный проблемный запрос. Просто есть у нас один постоянно работающий процесс - он как индикатор появляющихся проблем. Объем данных, который обрабатывается за час, стал уменьшаться. В день данных приходит больше, чем обрабатывается.
Вместе с этим увидел, что в базе за последние 2 месяца вырос тип ожидания WRITELOG.
Оптимизировал все "дыры" в процессе-индикаторе, покопал запросы, оказывающие наибольшую нагрузку на io-систему, точечно построил индексы по ключевым процессам. В общем, я не наблюдаю каких-то проблем в базе(какой-то запрос\запросы тормозит\стал хуже работать), но наблюдаю факт(просто все стало немного хуже работать), что нагрузка на диск повышенная. Это подтверждает диагностика в системном мониторе Windows: средняя длина очереди диска высокая.

Вопросы:
1) может ли быть, что дело не в MS SQL, а повысилась нагрузка на хранилище, которое общее для многих виртуалок?
2) Как можно это гарантированно диагностировать\подтвердить для аргументации начальству\админу?

p.s. планируем апгрейд MS SQL на новую версию с переходом на новый win-сервер, который будет на другом хранилище. Если, скажем так, проблема в хранилище, может как-то форсирую более скорый переход.
---
Проходя мимо разложенных граблей, ты теряешь драгоценный опыт. (с)

Все джобы я контролирую. В каждой итерации запускается обработка 1000 записей. В нормальное время это гарантировано отрабатывало за 2 минуты. Сейчас за 8. Ничего не срубается автоматом.
По всем большим таблицам есть большинство необходимых индексов. По многим большим таблицам старые данные перенесены в лог, за исключением одной много где используемой. Там была настроена архивация(переброска данных в архивную БД) конкретного кол-ва записей. А объем новых данных за сутки вырос. Работа с таблицей не самая оптимальная, к сожалению, но я не все запросы могу исправить на данный момент. А юзается она очень сильно, через многие наши процессы проходит, в том числе и через проблемный. В итоге при норме 10млн там сейчас 28млн. Это моя последняя надежда, что проблема в БД. :) Пока еще не решил ее, руки не дошли.

Модель полная, т.к. у нас зеркалирование. Оно работает только для полной модели.

Бэкапы ночью делаются, да. Но в общем данные по проблемному процессу за день как раз ночью дозагружаются за сутки, т.к. нагрузка на БД в целом ниже, даже с бэкапами.

Спасибо, попробую.

1) В данном случае я именно про всю БД в целом писал. Конкретный индикаторный процесс стал сильно хуже, БД в целом работает немного хуже. Других тормозов нет в системе, все штатно работает без заметных задержек.

2) Да все смотрю.

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

По виртуалке, дискам и прочему железу я, честно, не спец. Да и за это у нас сисадмин отвечает. Мне задач по БД с головой хватает. Я лишь запускал системный монитор машины, где стоит сервер БД, там есть стандартный счетчик производительности windows. По нему лишь увидел подтверждение повышенной нагрузки на дисковую подсистему.
Но это лишь фиксатор проблемы. Если порекомендуете систему мониторинга конкретную, я пну начальство и админа рассмотреть.

[quot Massa52#22025342]
Недавно перегружали, неделю назад где-то, правда не весь сервер, а службу MS SQL. Но как бы это к чему вообще, поясните?)


Спасибо, поищу, сам поизучаю, как минимум, для общего развития.

Что сделал сам по базе давно:
1) Есть история изменения типов ожиданий(в %). Собственно по ней я и определил, что сильно вырос WRITELOG. Последние 3 года впереди были другие типы ожиданий.

2) Есть история показателей среднего времени чтения и записи по файлам БД.

Но это я про БД.


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

Насчет памяти. Попробую выяснить этот момент.Возможно как-то этот момент зафиксировать на сервере через скрипт?
Мне казалось, вот выделили серверу MS SQL столько-то памяти, столько он и юзает(max server memory настроено). Поясните, проблема может быть на уровне ms sql vs виртуалка, на которой он стоит ms sql? На виртуалке с MS SQL больше ничего не стоит, кроме ОС.

Понаблюдал. Типы ожиданий: чаще WRITELOG, DBMIRROR_DBM_EVENT, изредка PAGEIOLATCH_SH и IO_COMPLETION.
Впрочем типы ожидания и потребляемые ресурсы я итак видел через нашу процу - монитор текущих процессов.
Поле blocking_session_id вообще никогда не заполнено. resource_description заполнено очень редко. У нас там 2 джоба параллельно работают: один делает чуть больше вычислений(доп. шаг джоба, раньше было 2 доп. шага) и за итерацию обрабатывает 1000 записей, второй - делает чуть меньше вычислений и за итерацию 50 записей. В редких случаях они пересекаются на вставку\обновление.

Да. Тоже подумывал, что может проблема в зеркалировании. Потому как на другом не главном сервере сталкивались с этим. Зеркальный сервер был построен на более медленном хранилище, как выяснилось путем тестов. Отключили зеркало, проблемы на основном исчезли.

p.s. Вечером\ночью проблемный процесс отрабатывает быстрее, т.к. общая нагрузка на БД существенно ниже. При этом стал сильно проседать при бэкапировании, чего раньше не наблюдалось.