Анализ производительности ввода-вывода — SQL Server на виртуальных машинах Azure

Область применения:SQL Server на виртуальной машине Azure

В этой статье описано, как проанализировать производительность ввода-вывода для SQL Server на виртуальных машинах Azure, чтобы выявить проблемы, возникающие в результате превышения ограничений на виртуальные машины и дисковые хранилища.

Обзор

Несмотря на то, что различные средства помогают устранять проблемы с производительностью SQL Server, для эффективного работы на виртуальной машине Azure важно понимать, что происходит как на уровне узла, так и в экземпляре SQL Server, где часто корреляция метрик узла с рабочими нагрузками SQL Server может быть проблемой. SQL Server на виртуальных машинах Azure упрощает определение проблем с производительностью, связанных с IOPS (операции ввода-вывода в секунду) и ограничением пропускной способности, вызванным превышением предельных значений виртуальных машин и дисков данных.

Метрики производительности, демонстрирующие проблему, и потенциальные шаги по ее устранению, доступны в портал Azure и запрашиваемые с помощью Azure CLI.

Область хранилища в ресурсе SQL виртуальных машин в портале Azure поможет вам:

• Управление конфигурацией хранилища
• Определение регулирования ввода-вывода
• Оцените вашу систему на предмет лучших практик, связанных с вводом-выводом.

Общие сведения о метриках

Вкладка "Анализ ввода-вывода" использует метрики Azure для определения задержки диска и регулирования операций ввода-вывода виртуальной машины или диска. Метрики Azure отбираются каждые 30 секунд и агрегируются в течение минуты.

Система отслеживает ограничение и задержку доступа к диску. Ожидается некоторое регулирование, которое игнорируется, если также нет задержки на диске. Если более 500 миллисекунда задержки диска наблюдается в течение 5-минутного периода, система:

• Углубленный анализ метрик производительности
• Определяет ограничиваемый ресурс
• Предоставляет потенциальные первопричины и шаги по устранению рисков

В следующей таблице описаны метрики Azure, используемые для выявления проблем с регулированием:

Результаты анализа операций ввода-вывода

На основе анализа метрик производительности за последние 24 часа анализ ввода-вывода определяет, что есть:

• Регулирование не выполняется
• Регулирование уровня ввода-вывода виртуальной машины
• Регулирование уровня дискового ввода-вывода

Нет проблемы с регулированием ввода-вывода

Если у вас возникла проблема с производительностью, но задержка на диске отсутствует, проблема с производительностью не возникает из-за проблемы регулирования ввода-вывода. Вам потребуется изучить другие области. Вы можете использовать контрольный список рекомендаций для SQL Server на виртуальных машинах Azure, чтобы убедиться, что система настроена эффективно или найти полезные ссылки для устранения неполадок с производительностью SQL Server. Если вы включите функцию оценки лучших практик SQL, вы сможете увидеть полный список рекомендаций для вашей виртуальной машины SQL Server.

Проблема регулирования уровня ввода-вывода виртуальной машины

Виртуальные машины Azure — это облачные вычислительные ресурсы, которые входят в разные серии и размеры различных рабочих нагрузок, каждый из которых имеет различные возможности и характеристики производительности. Как правило, для рабочих нагрузок SQL Server рекомендуется использовать ряды рабочих нагрузок SQL Server, оптимизированные для памяти, такие как серия Ebdsv5, M и Mv2.

Размер виртуальной машины определяет количество виртуальных ЦП, памяти и хранилища, доступных для экземпляра SQL Server. По сравнению с хранилищем, пользователи могут изменять размер виртуальных машин и масштабировать виртуальную машину вверх и вниз в зависимости от потребностей в ресурсах приложения. Поскольку операции ввода-вывода в секунду (IOPS) и пропускная способность могут ограничиваться на уровне виртуальной машины, выберите соответствующий размер виртуальной машины с учетом потребностей в производительности и стоимости рабочей нагрузки.

При миграции в Azure можно использовать средство рекомендаций SKU , чтобы проанализировать текущую конфигурацию и использование SQL Server и предложить оптимальный размер виртуальной машины для рабочей нагрузки в Azure.

Следующие метрики Azure используются для мониторинга регулирования рабочей нагрузки с целью предотвращения превышения ограничений, установленных виртуальной машиной.

• Процент потребленного кэшированного IOPS виртуальной машины
• Процент использования кэшированной пропускной способности виртуальной машиной
• Процент использования некэшированных IOPS виртуальной машиной
• Процент использования некэшированной пропускной способности виртуальной машиной

Рассмотрим следующие ключевые моменты регулирования виртуальных машин:

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

Проблема ограничения ввода/вывода на уровне диска

Для клиентов виртуальных машин SQL хранилище является наиболее важным аспектом настройки оптимальной производительности, так как изменение хранилища является более сложным, чем изменение размера виртуальной машины. Например, внесение изменений в увеличение операций ввода-вывода в секунду или пропускную способность дисков SSD уровня "Премиум" требует создания нового пула носителей. Таким образом, важно оптимизировать конфигурацию хранилища для цен и производительности во время этапа планирования, чтобы избежать проблем с производительностью после развертывания.

Следующие метрики Azure используются для определения ограничения рабочей нагрузки, чтобы предотвратить превышение ограничений, введённых диском.

• Процент использованных операций IOPS для диска данных

• Процент использования пропускной способности диска данных Рассмотрим следующие ключевые моменты регулирования уровня дискового ввода-вывода:

• Диск данных критически важен для производительности SQL Server. Рекомендуется размещать файлы данных SQL Server (.mdf) и журналов (df) на диске данных.

• Для ограничения на уровне диска данных включите кэширование чтения, если оно доступно.

Процент использованных операций IOPS для диска данных

Метрика "Процент использования IOPS диска" измеряет потребление операций ввода-вывода в секунду на уровне диска. Как правило, потребности с высоким уровнем ввода-вывода в секунду связаны с высокотранзакционными приложениями и рабочими нагрузками на основе OLTP.   Следующие сценарии или условия могут превышать лимиты IOPS для дисков данных.

• Высокая рабочая нагрузка транзакций (IOPS): Если приложение обрабатывает большой объем транзакций базы данных, включающих частые операции чтения и записи, оно может быстро использовать выделенные IOPS. 
• Неэффективные запросы: плохо оптимизированные SQL-запросы или операции извлечения данных могут привести к чрезмерной загрузке ввода-вывода, потребляя больше операций, чем ожидалось. 
• Одновременные пользователи: если несколько пользователей или сеансов одновременно обращаются к базе данных и создают запросы ввода-вывода, совокупный эффект может привести к достижению ограничения операций ввода-вывода. 
• Конкуренция за ресурсы: Если базовая физическая инфраструктура интенсивно используется другими клиентами или рабочими нагрузками, это может повлиять на доступные IOPS для вашей виртуальной машины. 
• Временные пики: временные пики рабочей нагрузки, такие как пакетная обработка или миграция данных, могут привести к внезапному увеличению спроса на операции ввода-вывода, которые превышают выделенные операции ввода-вывода. 
• Небольшой размер диска данных: если размер подготовленного диска данных относительно мал, емкость IOPS может быть ограничена. Отдельные небольшие диски имеют более низкие лимиты IOPS, и если требования приложения превышают этот лимит, "Процент потребления IOPS диска данных" достигает 100 %. 
• Недостаточный тип диска: Выбор типа диска с низкой производительностью (например, HDD уровня "Стандартный") для приложения с интенсивным вводом-выводом может привести к ограничениям на количество операций ввода-вывода. 
• Неоптимизированный размер сегмента диска: если конфигурация хранилища не оптимизирована для рабочей нагрузки, это может привести к низкой производительности IOPS. 

Чтобы избежать превышения ограничения IOPS для диска данных, выполните следующие шаги.

• Оптимизируйте запросы SQL и структуру базы данных, чтобы свести к минимуму ненужные операции ввода-вывода. 
• Выберите подходящий тип диска (SSD уровня "Стандартный" или SSD уровня "Премиум"), который соответствует требованиям по количеству операций ввода-вывода в секунду (IOPS) вашего приложения. 
• Используйте более крупные размеры дисков, чтобы увеличить доступную производительность IOPS. 
• Распределяйте операции ввода-вывода на нескольких дисках данных с помощью конфигураций RAID. 

Процент использования пропускной способности диска данных

Процент использования пропускной способности диска данных в Azure измеряет использование пропускной способности на уровне диска. Как правило, требования к высокой пропускной способности связаны с хранилищем данных, киоском данных, отчетом, ETL и другими рабочими нагрузками аналитики данных.

Следующие сценарии или условия могут превышать ограничения пропускной способности диска данных:

• Передача больших данных: часто масштабируемые передачи данных приложения между диском и базой данных SQL могут быстро использовать доступную пропускную способность диска данных. 
• Массовая загрузка данных: операции передачи дисков, связанные с массовыми вставками, обновлениями или импортами, могут привести к высокой пропускной способности. 
• Хранение данных или аналитика: приложения, включающие большие объемы хранения данных, обработку аналитики или отчеты, могут создавать существенное перемещение данных, что может привести к превышению ограничений пропускной способности.
• Технология высокой избыточности данных / репликация: копирование данных, связанное с использованием репликации на основе дисков, зеркалирования данных или других механизмов избыточности, может привести к насыщению пропускной способности. 
• Резервное копирование и восстановление данных: частые резервные копии данных, моментальные снимки или процессы восстановления могут использовать значительную пропускную способность диска данных. 
• Параллельное выполнение запросов: параллельные запросы, включающие сканирование больших данных или соединения, могут привести к существенному перемещению данных, что приводит к использованию пропускной способности. 
• Повышенный сетевой трафик: высокая сетевая активность, например передача данных между виртуальной машиной и другими ресурсами, может косвенно повлиять на доступность пропускной способности диска данных. 
• Недостаточного типа диска. Выбор типа диска с более низкой производительностью для приложения с высокими требованиями к передаче данных может привести к превышению ограничения пропускной способности. 
• Одновременные операции с интенсивными данными. Объединенный эффект нескольких параллельных процессов или сеансов, обращаюющихся к данным на одном диске, может привести к достижению ограничения пропускной способности. 
• Неоптимизированные запросы или процессы ETL: плохо оптимизированные запросы SQL или извлечение, преобразование, загрузка (ETL) могут привести к чрезмерному перемещению данных, что приводит к чрезмерному потреблению пропускной способности. 

Рассмотрите следующие действия, чтобы избежать превышения ограничения пропускной способности диска данных.

• Оптимизируйте операции передачи данных, чтобы свести к минимуму ненужные перемещения данных. 
• Рекомендуется использовать типы дисков с более высокой производительностью, которые обеспечивают большую пропускную способность, например SSD уровня "Премиум" или SSD уровня "Премиум" версии 2.
• Распределяйте данные по нескольким дискам с помощью таких методов, как секционирование или сегментирование.
• Оптимизация и параллелизация запросов и обработки данных для уменьшения перемещения данных.
• Используйте механизмы сжатия и эффективного хранилища данных, чтобы уменьшить объем передаваемых данных.
• Отслеживайте метрики производительности и масштабируйте конфигурации хранилища по мере необходимости. SSD "Премиум" версии 2 позволяет клиентам по требованию масштабировать IOPS и пропускную способность в соответствии с их потребностями.
• Важно регулярно отслеживать и анализировать метрики производительности, чтобы определить причину ограничений операций ввода-вывода в секунду и предпринять соответствующие действия для оптимизации производительности хранилища для виртуальной машины SQL.

Задержка без дросселирования

Задержка без регулирования относится к задержкам в доступе к данным или обработке, которые происходят даже в том случае, если система хранения не достигает максимальных ограничений операций ввода-вывода в секунду или пропускной способности. Задержка в виртуальных машинах Azure может возникать из различных источников, включая стек ввода-вывода операционной системы, обработку SQL Server, нагрузку на сеть или планирование гипервизора. Определение причины задержки важно для оптимизации производительности SQL Server на виртуальных машинах Azure.

Вы увидите следующее предупреждение на вкладке «Анализ ввода-вывода» панели хранилища, если обнаружена задержка без дросселирования. Warning: High disk latency detected without throttling

Ниже перечислены возможные причины задержки без ограничения скорости:

• Высокая загрузка ЦП: тяжелая загрузка ЦП может замедлить операции ввода-вывода, так как ЦП занят задачами шифрования, сжатия или выполнения запросов. Это особенно распространено в виртуальных машинах с меньшим количеством ядер. Если циклы ЦП недоступны, запросы ввода-вывода могут ждать больше обработки, увеличивая задержку даже в том случае, если ограничения хранилища не достигаются. Например, виртуальная машина с интенсивным процессом ЦП, например шифрование данных, может отложить операции ввода-вывода SQL Server, что приводит к замедлению времени отклика запросов.
• Недостаточно памяти на виртуальной машине. В SQL Server память критически важна для кэширования данных, что снижает потребность в операций ввода-вывода диска. Если память ограничена, SQL Server может потребоваться считывать с диска чаще, что увеличивает задержку. Это особенно важно в виртуальных машинах с меньшей памятью или когда ресурсоемкие фоновые процессы конкурируют за ресурсы. Это может косвенно увеличить задержку хранения, так как для обработки рабочей нагрузки требуются более частые операции с дисками, даже если ограничения операций ввода-вывода в секунду не достигнуты.
• Фоновые процессы: другие процессы на виртуальной машине, такие как антивирусное программное обеспечение, резервное копирование или задачи обслуживания (например, Центр обновления Windows) могут использовать ресурсы ЦП, памяти или дискового ввода-вывода, которые задерживают операции SQL Server. Неэффективные драйверы фильтров могут ухудшать этот эффект. Эти процессы конкурируют с SQL Server для системных ресурсов, что приводит к задержкам ввода-вывода, которые отображаются как задержка хранилища. Например, антивирусная проверка, которая считывает множество файлов одновременно, может снизить пропускную способность диска, доступную sql Server, что повышает задержку для транзакций базы данных. Кроме того, отсутствие правильных исключений антивирусной программы может привести к проблемам задержки без снижения производительности в среде SQL Server на виртуальных машинах Azure, главным образом за счет увеличения операций ввода-вывода на диске, вмешательства драйверов фильтрации и конкуренции ресурсов.
• Использование хранилища низкого уровня: выбор вариантов хранилища более низкого уровня, таких как стандартные жесткие диски вместо дисков категории "Премиум" или "Ультра", приводит к более высоким базовым задержкам из-за их внутреннего устройства, даже без достижения предела операций ввода-вывода в секунду (IOPS). Хотя экономичное хранилище более низкого уровня не оптимизировано для рабочих нагрузок SQL Server с учетом производительности, что приводит к снижению доступа к данным. Например, клиент, использующий жесткие диски уровня "Стандартный" для экономии затрат, может снизить производительность запросов из-за естественной задержки дисков.
• Неадекватная конфигурация хранилища. Не удалось настроить хранилище для оптимизации рабочих нагрузок SQL Server, что может привести к задержке без регулирования. Например, неправильные параметры кэширования дисков могут снизить производительность. Корпорация Майкрософт рекомендует включить кэширование только для чтения для дисков данных и отключить кэширование дисков журналов при использовании SSD уровня "Премиум" версии 1 с SQL Server на виртуальных машинах Azure. Неправильно настроенное кэширование может замедлить операции чтения или записи. Например, отключение кэширования чтения на диске данных, на котором размещаются файлы данных SQL Server, снижает эффективность рабочих нагрузок с большим объемом чтения, увеличивая задержку.
• Конкуренция запросов к базе данных SQL Server: неэффективные запросы (например, полное сканирование таблицы вместо индексированного поиска) или конкуренция за блокировки в SQL Server могут привести к увеличению потребности в операции ввода-вывода или задержке доступа к данным, что выражается в виде задержки хранилища. Проблемы на уровне приложения могут напрягать подсистему хранения без превышения ограничений, особенно с небольшими, случайными шаблонами ввода-вывода, распространенными в транзакционных рабочих нагрузках. Например, плохо оптимизированный запрос, выполняющий полную проверку таблицы в большом наборе данных, будет считывать избыточные данные с диска, повышая нагрузку ввода-вывода и задержку по сравнению с индексированных запросов.

Если вы испытываете задержку без ограничения скорости, попробуйте следующие шаги, чтобы устранить задержку:

• Мониторинг использования ЦП и управление ими. Отслеживание использования ЦП с помощью таких средств, как Azure Monitor или Resource Monitor. Если загрузка ЦП высока, оптимизируйте запросы SQL или обновите ее до виртуальной машины с большим количеством виртуальных ядер.
• Мониторинг использования памяти. Убедитесь, что размер виртуальной машины имеет достаточную память для рабочей нагрузки SQL Server, используя такие размеры виртуальных машин , как серии E или серии M с более высокими коэффициентами памяти к виртуальным ядрам. Мониторинг использования памяти с помощью монитора производительности или Azure Monitor для выявления точек давления. При необходимости рассмотрите возможность масштабирования памяти.
• Тщательно запланируйте фоновые задачи: выполняйте задачи с большим объемом ресурсов (например, резервные копии или антивирусная проверка) в нерабочее время, чтобы избежать конкуренции с SQL Server для ресурсов.
• Выберите нужный уровень хранилища: оцените, соответствует ли хранилище нижнего уровня (например, стандартные жесткие диски) вашим потребностям в производительности. Для критически важных рабочих нагрузок SQL Server выберите диски SSD уровня "Премиум" или "Ультра", чтобы свести к минимуму задержку.
• Правильно настроить кэширование: для SSD уровня "Премиум" (версия 1) установите кэширование только для чтения для дисков данных и без кэширования для дисков журналов. Проверьте параметры после изменений виртуальной машины или хранилища, так как диски SSD уровня "Премиум" версии 2 и "Ультра" не поддерживают кэширование.
• Оптимизация производительности SQL Server: проверка и настройка запросов для уменьшения спроса на ввод-вывод. Реализуйте индексы, избегайте полного сканирования таблиц и разрешайте проблемы с блокировками для повышения эффективности работы. Используйте функцию анализа рекомендаций для определения параметров конфигурации, которые могут повысить производительность.
• Убедитесь, что исключения антивирусной программы верны: реализация надлежащих исключений, тестирование под нагрузкой и планирование проверок могут соответствующим образом снизить задержки, обеспечивая оптимальную производительность с балансом безопасности.

Лучшие практики, связанные с вводом-выводом

Так как плохо настроенные системы хранения могут привести к проблемам с производительностью, вы можете использовать панель Хранилище в портале Azure, чтобы запускать подмножество правил оценки лучших практик SQL, предназначенное для дисков, для выявления проблем конфигурации хранилища с SQL Server на виртуальных машинах Azure. Функция лучших практик SQL основана на API оценки SQL.

Полный список рекомендаций можно просмотреть на сайте GitHub. Отфильтровав столбец ID в правилах GitHub, можно просмотреть правила конфигурации диска виртуальной машины SQL, которые проверяются на вкладке передовых методов настройки ввода-вывода на панели хранилища для ресурса виртуальные машины SQL в портале Azure.

На вкладке рекомендаций, связанных с вводом-выводом, используйте Запустить оценку для начала оценки конфигурации, которая займет несколько минут (если нет большого количества баз данных и объектов). Кроме того, если отображается метка времени для последних доступных результатов, можно использовать Получить последние результаты, чтобы просмотреть результаты предыдущих оценок.

Анализ ввода-вывода с помощью PowerShell

Вы также можете использовать скрипт PowerShell для анализа производительности ввода-вывода виртуальной машины SQL Server:

# Enter parameters
$subscriptionId = Read-Host "<Subscription ID>"
$resourceGroup = Read-Host "<Resource Group>"
$vmName = Read-Host "<Virtual machine name>"

# Set resource details
$resourceType = "Microsoft.Compute/virtualMachines"
$resourceId = "/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/$resourceType/$vmName"

# Get Azure access token
$accessToken = az account get-access-token --query accessToken -o tsv

# Invoke Azure Monitor Metrics API
function Get-Metrics {
    [CmdletBinding()]
    param (
        [string]$accessToken,
        [string]$resourceId,
        [string]$metricNames,
        [string]$apiVersion = "2023-10-01"
    )
    try {
        $startTime = (Get-Date).AddHours(-24).ToUniversalTime().ToString('yyyy-MM-ddTHH:mm:ssZ')
        $endTime = (Get-Date).ToUniversalTime().ToString('yyyy-MM-ddTHH:mm:ssZ')
        $timespan = "$startTime/$endTime"
        Write-Verbose "Evaluating timespan: $timespan"
        $uri = "https://management.azure.com$resourceId/providers/Microsoft.Insights/metrics?api-version=$apiVersion&metricnames=$metricNames&aggregation=maximum&interval=PT1M&timespan=$timespan"
        $headers = @{ "Authorization" = "Bearer $accessToken"; "Content-Type" = "application/json" }
        
        $response = Invoke-RestMethod -Uri $uri -Headers $headers -Method Get
        if ($response) {
            Write-Verbose "API response successfully retrieved."
            return $response
        } else {
            Write-Error "No response from API."
        }
    } catch {
        Write-Error "Error retrieving metrics: $_"
    }
}

# Check if data disk latency violates thresholds
function Check-Latency {
    [CmdletBinding()]
    param (
        [Parameter(Mandatory = $true)]
        [Object]$metrics,

        [Parameter()]
        [int]$latencyThreshold = 500,

        [Parameter()]
        [int]$consecutiveCount = 5
    )
    $violationTimes = @()
    foreach ($metric in $metrics.value) {
        if ($metric.name.value -eq "Data Disk Latency") {
            $count = 0
            foreach ($dataPoint in $metric.timeseries[0].data) {
                if ($dataPoint.maximum -gt $latencyThreshold) {
                    $count++
                    if ($count -ge $consecutiveCount) {
                        $violationTimes += $dataPoint.timeStamp
                        $count = 0  # Reset count after recording a violation
                    }
                } else {
                    $count = 0  # Reset count if the sequence is broken
                }
            }
        }
    }
    if ($violationTimes.Count -gt 0) {
        Write-Verbose "Latency violations detected."
        return @{ "Flag" = $true; "Times" = $violationTimes }
    } else {
        Write-Verbose "No latency violations detected."
        return @{ "Flag" = $false }
    }
}

# Check metrics other than latency to evaluate for throttling
function Check-OtherMetricsThrottled {
    [CmdletBinding()]
    param (
        [Parameter(Mandatory = $true)]
        [Object]$metrics,

        [Parameter()]
        [int]$PercentageThreshold = 90,

        [Parameter()]
        [int]$consecutiveCount = 5
    )
    $violatedMetrics = @()
    foreach ($metric in $metrics.value) {
        $count = 0
        foreach ($dataPoint in $metric.timeseries[0].data) {
            if ($dataPoint.maximum -gt $PercentageThreshold) {
                $count++
                if ($count -ge $consecutiveCount) {
                    $violatedMetrics += @{ "Metric" = $metric.name.localizedValue; "Time" = $dataPoint.timeStamp; "Value" = $dataPoint.maximum }
                    break
                }
            } else {
                $count = 0
            }
        }
    }
    if ($violatedMetrics.Count -gt 0) {
        Write-Verbose "Other metrics violations detected."
    } else {
        Write-Verbose "No other metrics violations detected."
    }
    return $violatedMetrics
}

# Compare times for latency & other throttled metrics. Logs the volations with values & timestamps
function CompareTimes {
    [CmdletBinding()]
    param (
        [Parameter(Mandatory = $true)]
        [Hashtable]$latencyResult,
        
        [Parameter(Mandatory = $true)]
        [Array]$otherMetrics
    )
    foreach ($metric in $otherMetrics) {
        $otherDateTime = [DateTime]$metric["Time"]
        $isWithinFiveMinutes = $false
        $closestLatencyTime = $null
        $closestTimeDifference = [int]::MaxValue

        foreach ($latencyTime in $latencyResult.Times) {
            $latencyDateTime = [DateTime]$latencyTime
            $timeDifference = [Math]::Abs(($otherDateTime - $latencyDateTime).TotalMinutes)
            
            if ($timeDifference -le 5) {
                $isWithinFiveMinutes = $true
                if ($timeDifference -lt $closestTimeDifference) {
                    $closestTimeDifference = $timeDifference
                    $closestLatencyTime = $latencyTime
                }
            }
        }

        if ($isWithinFiveMinutes) {
            if ($otherDateTime -lt $closestLatencyTime) {
                Write-Host "`n $($metric["Metric"]) limit was hit before latency spiked at $closestLatencyTime with value $($metric["Value"]). `n"
            } else {
                Write-Host "`n $($metric["Metric"]) hit its limit with value $($metric["Value"]) at $($metric["Time"])."
                Write-Host "Latency spiked at $closestLatencyTime before $($metric["Metric"]) hit its limit `n"
            }
        } else {
            Write-Host "`n Metric: $($metric["Metric"]) exceeded its threshold with a value of $($metric["Value"]) at $($metric["Time"]), but this was not within 5 minutes of any latency spikes."
        }
    }
}

# Prompt user for latency threshold
$latencyThreshold = Read-Host "Enter Latency Threshold (default is 500)"
if (-not [int]::TryParse($latencyThreshold, [ref]0)) {
    $latencyThreshold = 500 # Use default if invalid input
    Write-Host "No valid input provided. Using Default 500ms for disk latency threshold"
}

# Execute main logic
$latencyMetrics = Get-Metrics -accessToken $accessToken -resourceId $resourceId -metricNames "Data Disk Latency"
$latencyResult = Check-Latency -metrics $latencyMetrics -latencyThreshold $latencyThreshold

if ($latencyResult.Flag) {
    
    # If latency is flagged, check for other metrics. If there is no disk latency, machine is likely not throttled but only at high consumption
    Write-Verbose "Checking the following metrics: Data Disk Bandwidth Consumed Percentage,Data Disk IOPS Consumed Percentage,VM Cached Bandwidth Consumed Percentage,VM Cached IOPS Consumed Percentage,VM Uncached Bandwidth Consumed Percentage,VM Uncached IOPS Consumed Percentage"
    
    $DiskVMMetrics = Get-Metrics -accessToken $accessToken -resourceId $resourceId -metricNames "Data Disk Bandwidth Consumed Percentage,Data Disk IOPS Consumed Percentage,VM Cached Bandwidth Consumed Percentage,VM Cached IOPS Consumed Percentage,VM Uncached Bandwidth Consumed Percentage,VM Uncached IOPS Consumed Percentage"
    
    $additionalMetrics = Check-OtherMetricsThrottled -metrics $DiskVMMetrics
    
    if ($additionalMetrics.Count -gt 0) {
        CompareTimes $latencyResult $additionalMetrics
    } else {
        Write-Host "No metrics violations detected besides latency."
    }
} else {
    Write-Host "No latency issues detected."
}

Следующие шаги

• Выполните оценку рекомендаций SQL, чтобы определить потенциальные неправильные конфигурации, которые могут привести к проблемам с производительностью.