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

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.


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

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

Подробности под катом.

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

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


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

image

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

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

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

image

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

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


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

image

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

image

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

image

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

image

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

image

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

image

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

image

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

image

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

image

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

image

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

image

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

Если вам понравился Foglight for Databases и вы хотели бы его попробовать на своих БД — оставьте заявку на получение дистрибутивов и триального ключа в форме обратной связи на нашем сайте. Стабильной работы баз данных и быстрой локализации нештатной работы!
Источник: https://habr.com/ru/company/galssoftware/blog/464963/


Интересные статьи

Интересные статьи

Ваш кандидат только что прошел последнее собеседование – ура! Вы получаете информацию от клиента о том, что он готов перейти к этапу контрольной проверки и после этого принять на работу к...
Файрвол не может блокировать трафик из macOS На прошлой неделе в интернете поднялась шумиха по поводу того, что Apple отслеживает каждый запуск каждого приложения в macOS — и отправл...
Нужно поставить оборудование на мониторинг, а в любимой системе Zabbix нет готового шаблона под этот тип оборудования. Знакомая ситуация? Каждый выкручивается из нее по-своему. Один администр...
Материал, первую часть перевода которого мы публикуем сегодня, посвящён масштабной проблеме, которая возникла в gitlab.com. Здесь пойдёт речь о том, как её обнаружили, как с ней боролись, и как, ...
Эта статья написана по материалам моего выступления на HR Meetup #5, проходившего 5 октября 2018 года в г. Ростове-на-Дону. О себе Меня зовут Игорь Шелудько. Я – предприниматель в сфере ...