Отладка с помощью схемы физических заданий (предварительная версия) в портал Azure

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

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

Внимание

Эта функция сейчас доступна в режиме предварительной версии. Юридические условия, применимые к функциям Azure, которые находятся в состоянии бета-версии, предварительной версии или иным образом еще не выпущены в общедоступной версии, см. на странице Дополнительные условия использования предварительных версий в Microsoft Azure.

Определение параллелизма задания

Задание с параллелизмом — это масштабируемый сценарий в Stream Analytics, который может обеспечить лучшую производительность. Если задание не находится в параллельном режиме, скорее всего, имеет определенное узкие места в производительности. Важно определить, находится ли задание в параллельном режиме или нет. Схема физических заданий предоставляет визуальный граф для иллюстрации параллелизма заданий. На схеме физических заданий, если между разными узлами потоковой передачи есть взаимодействие с данными, это задание является не параллельной задачей, требующей большего внимания. Например, на схеме не параллельных заданий ниже:

Вы можете оптимизировать его для параллельного задания (например, ниже), перезаписав запрос или обновив конфигурации входных и выходных данных с помощью симулятора схемы заданий в расширении ASA Visual Studio Code или редакторе запросов в портал Azure. Дополнительные сведения см. в статье "Оптимизация запроса с помощью симулятора схемы заданий (предварительная версия)".

Ключевые метрики для определения узких мест параллельного задания

Задержка и невыполненные входные события водяного знака — это ключевые метрики для определения производительности задания Stream Analytics. Если предельная задержка вашего задания постоянно увеличивается, а входные события остаются необработанными, это означает, что задание не в состоянии поддерживать скорость входных событий и своевременно создавать выходные данные. С точки зрения вычислительного ресурса ресурсы ЦП и памяти используются на высоком уровне, когда это происходит.

Схема физических заданий визуализирует эти ключевые метрики на схеме вместе, чтобы обеспечить полное представление о них для выявления узких мест.

Дополнительные сведения об определении метрик см. в измерении имени узла Azure Stream Analytics.

Определение неровных распределенных входных событий (отклонение данных)

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

Чтобы найти первопричину, откройте схему физических заданий в портал Azure. Выберите схему заданий (предварительная версия) в разделе "Мониторинг" и перейдите на физическую схему.

На физической схеме можно легко определить, имеют ли все секции высокую задержку водяного знака, или лишь несколько из них, просмотрев значение задержки водяного знака в каждом узле или выбрав параметр задержки тепловой карты для сортировки узлов потоковой передачи (рекомендуется):

После применения параметров тепловой карты, сделанных выше, вы получите узлы потоковой передачи с высокой задержкой подложки в верхнем левом углу. Затем можно проверить, имеют ли соответствующие узлы потоковой передачи значительно больше входных событий, чем другие. В этом примере потоковая передача#0 и streamingnode#1 имеют больше событий ввода.

Кроме того, можно проверить, сколько секций выделяется узлам потоковой передачи по отдельности, чтобы узнать, вызваны ли дополнительные входные события, выделенные секциями или любой конкретной секцией с большим количеством входных событий. В этом примере все узлы потоковой передачи имеют две секции. Это означает, что streamnode#0 и streamingnode#1 имеют определенную секцию, содержащую больше входных событий, чем другие секции.

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

• Выбор " Добавить диаграмму " в разделе диаграммы
• Добавление входных событий в метрики и идентификатор секции в разделитель
• Выберите "Применить" , чтобы открыть диаграмму входных событий
• Тик streamingnode#0 и streamingnode#1 на схеме

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

Какие дальнейшие действия можно предпринять?

Как показано в примере, секции (0 и 1) имеют больше входных данных, чем другие секции. Мы называем это неравномерное распределение данных. Узлы потоковой передачи, обрабатывающие секции с распределением данных, должны использовать больше ресурсов ЦП и памяти, чем другие. Этот дисбаланс приводит к замедлению производительности и увеличивает задержку водяного знака. Вы можете проверить использование ЦП и памяти на двух узлах потоковой передачи, а также на физической схеме. Чтобы устранить проблему, необходимо перераспределить входные данные более равномерно.

Определение причины перегрузки ЦП или памяти

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

1. Откройте схему физического задания, перейдите к заданию портал Azure в разделе "Мониторинг", выберите схему заданий (предварительная версия) и перейдите на физическую схему. Вы увидите физическую схему, загруженную как показано ниже.

   

2. Проверьте использование ЦП и памяти в каждом узле потоковой передачи, чтобы узнать, слишком ли загрузка во всех узлах потоковой передачи слишком высока. Если загрузка ЦП и SU высока (более 80 процентов) во всех узлах потоковой передачи, можно заключить, что это задание имеет большое количество данных, обрабатываемых в каждом узле потоковой передачи.

   В приведенном выше случае загрузка ЦП составляет около 90 %, а использование памяти уже составляет 100 %. В нем показано, что каждый узел потоковой передачи выходит из ресурса для обработки данных.

   

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

   В этом случае каждый узел потоковой передачи имеет четыре секции, которые выглядят слишком много для узла потоковой передачи.

Какие дальнейшие действия можно предпринять?

Рассмотрите возможность уменьшения количества секций для каждого узла потоковой передачи, чтобы уменьшить входные данные. Вы можете увеличить количество единиц SUS, выделенных каждому узлу потоковой передачи, до двух секций на узел, увеличив количество узлов потоковой передачи от 8 до 16. Кроме того, можно в четыре раза повысить количество единиц, чтобы каждый узел потоковой передачи обрабатывал данные из одной секции.

Дополнительные сведения о связи между узлом потоковой передачи и единицей потоковой передачи см. в разделе "Общие сведения об единице потоковой передачи" и узле потоковой передачи.

Что делать, если предельная задержка по-прежнему увеличивается, когда один узел потоковой передачи обрабатывает данные одной секции? Перераспределите входные данные с использованием дополнительных секций, чтобы уменьшить объем данных в каждой секции. Дополнительные сведения см. в статье Использование повторного секционирования для оптимизации заданий Azure Stream Analytics.

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

• Что такое Stream Analytics?
• Схема заданий Stream Analytics (предварительная версия) в портал Azure
• Метрики заданий Azure Stream Analytics
• Масштабирование заданий Azure Stream Analytics для повышения пропускной способности базы данных
• Stream Analytics Query Language Reference (Справочник по языку запросов Stream Analytics)
• Анализ производительности заданий Stream Analytics с помощью измерений и метрик