Запрос, который вчера выполнялся за 200 миллисекунд, сегодня выполняется 14 секунд. Команда приложения заметила это раньше, чем инструмент мониторинга. К тому моменту, когда кто-то открывает сервер базы данных, в представлении активных запросов находится 47 сеансов, три из них заблокированы, и один из них удерживает блокировку, которая открыта уже шесть минут. Никто не может сказать вам, что делает этот сеанс, кому он принадлежит и безопасно ли его завершить. Это не проблема оборудования. Это проблема видимости. И она встречается чаще, чем следовало бы. Давайте поговорим о представлениях производительности в реальном времени, которые упрощают устранение неполадок.
Разрыв между данными и диагностикой
SQL Server генерирует огромное количество данных о производительности в реальном времени. Одних только динамических административных представлений, включая sys.dm_exec_requests, sys.dm_os_wait_stats, sys.dm_exec_query_stats, sys.dm_exec_sessions и sys.dm_db_index_operational_stats, достаточно, чтобы администратор баз данных понял, что происходит в экземпляре в любой момент времени. Проблема не в доступности данных. Проблема в том, что сырой вывод динамических административных представлений не является интерфейсом для устранения неполадок.
Запрос к sys.dm_exec_requests с соединением с sys.dm_exec_sql_text и sys.dm_exec_query_plan даёт вам активный запрос, текст инструкции и кэшированный план выполнения. Это действительно полезно. Но писать такой запрос в стрессовой ситуации, в 9 вечера, пока кто-то ждёт обновления, — это совсем другой опыт по сравнению с тем, когда он представлен в представлении в реальном времени, которое обновляется каждые несколько секунд и подсвечивает важное. Платформы мониторинга существуют именно для того, чтобы отображать связи между этими динамическими административными представлениями в оперативном представлении в реальном времени, а не заставлять администраторов баз данных восстанавливать их вручную во время инцидента.
Представления производительности в реальном времени устраняют этот разрыв. При правильной реализации они берут те же самые нижележащие данные и представляют их таким образом, что сокращается время между открытием инструмента мониторинга и пониманием того, что делать дальше.
Что должно быть в представлении реального времени
Не всё подходит для динамической панели мониторинга. Загромождение представления реального времени показателями, которые имеют смысл только за часы или дни, такими как тенденции фрагментации индексов, рост хранилища и история резервного копирования, превращает диагностический инструмент в инструмент составления отчётов. У них разные цели.
Показатели, которые действительно заслуживают места в представлении для устранения неполадок в реальном времени, — это те, где изменение за последние 30–60 секунд имеет диагностическое значение. В таблице ниже для каждой категории показателей указан исходный источник DMV, соответствующий интервал сбора и то, что он на самом деле вам сообщает.
| Категория показателей | Основное DMV | Интервал сбора | Что это вам сообщает |
|---|---|---|---|
| Активные сеансы и блокировки | sys.dm_exec_requests, sys.dm_exec_sessions | От 15 до 30 секунд | Кто выполняется, кто заблокирован, как долго и какой тип ожидания. Отображается в виде дерева цепочки блокировок. |
| Дельта статистики ожидания | sys.dm_os_wait_stats (выборка с интервалами) | От 30 до 60 секунд | Скорость изменения показателей PAGEIOLATCH, LCK_M, CXPACKET, CXCONSUMER и SOS_SCHEDULER_YIELD. Не накопленные итоги. |
| Кэшированные планы выполнения | sys.dm_exec_query_plan, sys.dm_exec_text_query_plan | По запросу | Кэшированный план, который SQL Server использует для любого активного запроса. Используйте sys.dm_exec_query_profiles для данных на уровне операторов о выполняющемся запросе. |
| CPU запроса против исторического среднего | sys.dm_exec_requests, корреляция через query_hash с sys.dm_exec_query_stats | От 30 до 60 секунд | Является ли текущее выполнение аномальным или просто, как обычно, дорогим. query_hash связывает текущие запросы с их историческими агрегатами. |
| Нагрузка на tempdb | sys.dm_db_session_space_usage, sys.dm_db_task_space_usage, sys.dm_exec_requests | 60 секунд | Размер хранилища версий, конфликты распределения страниц и использование tempdb на сеанс и на задачу для полной картины нагрузки. |
| Нагрузка на память | sys.dm_os_performance_counters, sys.dm_exec_query_memory_grants | 60 секунд | Устойчивая нисходящая тенденция PLE (ожидаемой продолжительности жизни страницы), а не сырое значение, является сигналом. Ожидающие распределения памяти указывают на то, что рабочая нагрузка ожидает выделения памяти. |
Таблица 1: Категории показателей реального времени, их источники DMV и диагностическая ценность
Как архитектура сбора данных влияет на то, что вы видите
Поток данных прост. Источники DMV питают механизм сбора данных, который, в свою очередь, управляет представлениями реального времени, с которыми работает администратор баз данных. Интервалы сбора не произвольны. Они отражают реальный компромисс между диагностической разрешающей способностью и нагрузкой на отслеживаемый экземпляр.
Более высокая частота сбора означает большую нагрузку на отслеживаемый экземпляр и больше хранилища, потребляемого инфраструктурой мониторинга. Хорошо спроектированные инструменты управляют этим, применяя разные интервалы к разным категориям показателей: данные о живых сеансах с интервалом 15 секунд, дельта статистики ожидания — 60 секунд, показатели индексов и хранилища — с более длинными интервалами. Цель состоит в том, чтобы собирать то, что нужно собирать, без добавления значительной нагрузки на уже испытывающий давление экземпляр.
Для анализа цепочек блокировок частота сбора имеет большее значение, чем большинство людей осознают. Событие блокировки, которое разрешается за три минуты и вызывает всплеск ошибок приложения, может никогда не появиться в инструменте с пятиминутным циклом обновления. Сбор с разрешением менее минуты — это то, что позволяет фиксировать эти мимолётные события, сохранять их в истории и анализировать после того, как они уже разрешились.
Проблема с планами выполнения
Одна из самых недоиспользуемых возможностей при устранении неполадок в реальном времени — это доступ к кэшированному плану выполнения. sys.dm_exec_query_plan возвращает кэшированный план, связанный с выполняющимся запросом, то есть тот план, который SQL Server на самом деле использует для выполнения запроса и который нужен администратору баз данных во время инцидента. sys.dm_exec_text_query_plan возвращает его в формате XML, с возможностью фильтрации по смещению инструкции, что позволяет изолировать релевантный план для конкретной инструкции внутри пакета с несколькими инструкциями.
Важное различие заключается в том, что это кэшированный план, а не план выполнения в реальном времени, отражающий текущую статистику выполнения. Для статистики выполнения в реальном времени, такой как фактически обработанные строки на оператор и фактические оценки против оценочных, sys.dm_exec_query_profiles предоставляет данные на уровне операторов для активных запросов, хотя требует, чтобы запрос был скомпилирован с включённым сбором статистики выполнения. В большинстве инцидентов кэшированного плана из sys.dm_exec_query_plan достаточно для выявления проблемы.
Это важно, потому что запрос может хорошо работать при одном наборе условий и катастрофически — при другом, используя тот же кэшированный план. Если план, пострадавший от Sniffing параметров, который был оптимален для небольшого результирующего набора, теперь выполняется для большого, план сам покажет вам, где именно возникает проблема: на вложенном соединении (nested loop join), которое выполняется миллионы раз, на поиске по ключу (key lookup) против непокрывающего индекса или на хэш-соединении (hash match), которое сбросило данные на диск в tempdb. Вы не можете надёжно вывести это из одной только статистики ожидания.
Представление реального времени, которое отображает кэшированный план для любого выбранного активного запроса, визуализируя его графически, а не в виде сырого XML, превращает то, что раньше было многоэтапным расследованием, в один клик. Администратор баз данных видит запрос, видит план и может принять решение о том, является ли исправлением подсказка, индекс или обновление статистики, не покидая интерфейс мониторинга.
Почему частота обновления важнее, чем думают люди
Представление реального времени, которое обновляется каждые пять минут, не является представлением реального времени. Это медленный инструмент отчётности с оптимистичным названием.
Для анализа цепочек блокировок пятиминутное обновление означает, что вы можете никогда не увидеть событие блокировки, которое разрешается за три минуты, а это именно тот тип события, который вызывает всплеск ошибок приложения, а затем исчезает до того, как кто-либо проведёт расследование. Интервалы сбора менее минуты, обычно от 15 до 30 секунд для данных о живых сеансах, позволяют инструменту мониторинга фиксировать мимолётные события блокировки и сохранять их в исторических данных даже после того, как они разрешились.
Здесь есть реальный компромисс. Более высокая частота сбора означает большую нагрузку на отслеживаемый экземпляр и больше хранилища, потребляемого инфраструктурой мониторинга. Хорошо спроектированные инструменты управляют этим, применяя разные интервалы сбора к разным категориям показателей: данные о живых сеансах с интервалом 15 секунд, дельта статистики ожидания — 60 секунд, показатели индексов и хранилища — с более длинными интервалами. Цель состоит в том, чтобы собирать то, что нужно собирать, без добавления значительной нагрузки на уже испытывающий давление экземпляр.
Статистика ожидания: дельта вместо итогов
sys.dm_os_wait_stats является накопительной с момента последнего перезапуска службы. Сервер, который работает три недели, хранит три недели накопленной истории ожидания в каждой строке. Накопленный итог полезен для анализа тенденций за длительные периоды. Он не полезен для понимания того, что происходит прямо сейчас.
Сигнал, который вам нужен в контексте реального времени, — это скорость изменения. Насколько увеличились ожидания PAGEIOLATCH_EX за последние две минуты? Растут ли ожидания SOS_SCHEDULER_YIELD, указывая на насыщение процессора? Произошёл ли всплеск ASYNC_NETWORK_IO, который часто указывает на клиента, который не потребляет результирующие наборы данных достаточно быстро? Инструмент мониторинга, который делает выборку статистики ожидания с короткими интервалами и представляет дельту, а не нарастающий итог, выявляет нагрузку, которую накопительные представления полностью скрывают.
- PAGEIOLATCH_SH / PAGEIOLATCH_EX — ожидание страниц данных, считываемых с диска в буферный пул. Растущая дельта указывает на нагрузку дискового ввода-вывода или на «перемешивание» буферного пула из-за недостатка памяти.
- CXPACKET — ожидание параллельного обмена на стороне производителя. Растущая дельта вместе с высокой загрузкой процессора может указывать на неравномерность плана (plan skew), неправильную конфигурацию MAXDOP или рабочую нагрузку, которая излишне распараллеливается.
- CXCONSUMER — ожидание параллельного обмена на стороне потребителя, отделено от CXPACKET в SQL Server 2017 CU3. Обычно не является проблемой. Высокая дельта CXCONSUMER без соответствующего роста CXPACKET обычно не является сигналом для настройки.
- SOS_SCHEDULER_YIELD — поток добровольно уступил планировщик при высокой нагрузке на процессор. Растущая дельта означает, что экземпляр ограничен процессором.
- ASYNC_NETWORK_IO — SQL Server ожидает, пока клиент потребит данные. Часто это узкое место на стороне клиента, но оно всё равно занимает сеансы и может создавать видимую блокировку.
- LCK_M_X / LCK_M_S / LCK_M_U — ожидания блокировок. Любая значимая дельта здесь означает, что блокировка активна или была активна недавно. Представление сеансов покажет, кто в этом участвует.
Чтение представления в условиях стресса
Самое важное качество представления производительности в реальном времени — это то, что оно должно быть читаемым для человека, который уже находится в стрессе и действует быстро. Это звучит очевидно. Большинство интерфейсов мониторинга всё ещё упускают это из виду.
Эффективные представления реального времени начинаются с ответа. Если есть блокировка, представление блокировок должно быть первым видимым элементом, а не скрытым под меню навигации. Если тип ожидания резко вырос за последние две минуты, он должен визуально выделяться на фоне тех, которые не выросли. Если запрос потребляет в 10 раз больше процессора, чем обычно, это отклонение должно быть немедленно очевидным, не требуя от администратора баз данных запоминать обычное значение.
В этом разница между представлением, которое представляет данные, и представлением, которое поддерживает принятие решений. Нижележащие данные SQL Server одинаковы в обоих случаях. Разница в том, как они структурированы, отфильтрованы и представлены.
Комментариев нет:
Отправить комментарий