Хабрахабр

Быстрая локализация проблем производительности Microsoft SQL Server в Quest Foglight

Сегодня разберём подходы к быстрому выявлению причин нештатной работы Microsoft SQL Server: В прошлой статье об инструменте для мониторинга Foglight for Databases мы рассказывали о возможностях контроля из единого интерфейса SQL Server, Oracle, PostgreSQL, MySQL, SAP ASE, DB2, Cassandra и MongoDB.

  • Поиск источника блокировки;
  • Сравнение настроек БД «было-стало» с привязкой к метрикам производительности;
  • Поиск изменений в структуре БД, из-за которых снизилась производительность.

Подробности под катом.
Foglight for Databases — инструмент мониторинга за производительностью и изменениями в популярных базах данных. Если вы не знакомы с этим продуктом — рекомендуем прочитать предыдущую статью. А ниже мы привели скриншоты из интерфейса для демонстрации возможностей Foglight и простоты поиска проблем в БД.

Поиск источника блокировки

Поиск причины блокировок можно вести в Management Studio. Но рабочей станции с этой утилитой может не оказаться под рукой, да и открывать консоль не всегда удобно. В Quest Foglight найти причину блокировку можно за считанные клики. На скриншоте ниже вы видите основную консоль мониторинга баз данных.

image

В столбце Workload заметно красное поле, которое означает ненулевое значение параметра Lock Wait. Дежурный администратор, который уже получил уведомление, переходит в представление SQL PI (Performance Investigator).

image

Здесь, как и на скриншоте выше видно, что блокировка вызывает большую утилизацию ресурсов. После клика по графику Workload открывается детальное представление источников нагрузки на БД, а в столбце слева меню для проведения многомерного анализа производительности. В меню слева есть специальное представление Locked Objects, в котором и обнаружится заблокированный объект.

image

В правой части экрана причины блокировок: длительность, с какого сервера (или рабочей станции), какой программой, от какого пользователя и исполняемый объект, который привёл к блокировке. В Locked Objects хранятся заблокированные объекты.

image

И после нажатия на View Batch Text откроется исполненный код. При переходе на исполняемый объект, откроется новое представление с возможностью просмотра содержимого этого объекта.

image

Ускорение времени диагностики — залог успешной работы команды ИТ.

Сравнение настроек БД «было-стало»

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

image

В открывшемся меню нужно перейти на SQL PI (Performance Investigator), чтобы открыть представление с многомерным анализом.

image

Перейдём на представление Baseline для оценки поведения метрики в сравнении с её обычными значениями.

image

На графике видно, что после 13:40 начался аномальный рост потребления ресурсов.

image

Сейчас рассмотрим сравнение метрики самой с собой (по базовой линии), т.к. В это представлении настроим что с чем сравнивать. Вообще, можно также сравнить производительность и с другим экземпляром БД. выше выявили аномальное отклонение.

image

После выбора объектов для сравнения появится заветная кнопка Compare.

image

Начнём новое сравнение для выявления изменений. На среднем представлении видно, что аномальные значения наблюдались по метрикам: Active Time, Executions и Logins Rate.

image

Сравним значения метрик с самими собой, но день назад.

image

После выбора настроек, появится кнопка Compare, на которую нужно нажать.

image

Для демонстрации мы выберем пункт меню Programs. Появится представление, на котором есть измерения для сравнения. В разделе Statistics уже виден двукратный рост значения метрики Executions.

image

Здесь видим, что Active Time и Executions выросли почти в два раза, а это повод для проведения детального разбора ситуации. Слева и справа от шкалы в разделе меню Programs отображаются значения метрик.

image

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

Поиск изменений в структуре БД

Изменения индексов, execution plans и других объектов может носить недокументированный характер. Разработчик или администратор БД вносит, казалось бы, незначительные изменения, о которых через некоторое время может забыть. В интерфейсе Foglight for Databases изменения конфигурации привязываются к изменениям производительности. Для выявления изменений переходим с главного экрана мониторинга БД на представление Workload.

image

Раскрываем в представлении слева Client Machines. Допустим, нам известно, что с какой-то клиентской машины генерируется большая нагрузка на БД.

image

Перейдём на первый объект в списке и далее посмотрим изменения по нему (Change Tracking). Batches отсортированы в соответствии с создаваемой нагрузкой на БД.

image

Первое изменение здесь — удаление индекса, второе — добавление нового execution plan. На графике, согласно легенде справа, отмечены соответствующие изменения за выбранный период. Четвертое изменение — увеличение значения уровня параллелизма, что потенциально привело к повышение количества запросов (IO Wait — голубая зона). Как видно, после удаления индекса резко возросла нагрузка Other Wait — фиолетовая зона (к ней также относится выполнения batch job). Рассмотрим последствия добавления нового execution Plan.

image

Теперь сравним произошедшие изменения. После перехода открылись детали нового execution plan.

image

После перехода открылись детали нового execution plan.

image

Этот же execution plan можно открыть в Management Studio прямо из интерфейса Quest Foglight.

image

Так он выглядит в консоли Management Studio.

image

При переходе на представление History можно увидеть изменения метрик во времени.

image

Далее переходим на представление Other. Представление History можно использовать для оценки влияния изменений на ту или иную метрику.

image

Они уже отсортированы в порядке убывания. На этом представлении видно какие batches повлияли на нагрузку БД.

image

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

Стабильной работы баз данных и быстрой локализации нештатной работы! Если вам понравился Foglight for Databases и вы хотели бы его попробовать на своих БД — оставьте заявку на получение дистрибутивов и триального ключа в форме обратной связи на нашем сайте.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть