Анализ производительности заданий Stream Analytics с помощью измерений и метрик
Чтобы оценить производительность задания Stream Analytics, важно знать, как использовать метрики и измерения задания. Вы можете использовать портал Azure, расширение Stream Analytics Visual Studio Code или пакет SDK, чтобы получить интересующие вас метрики и измерения.
В этой статье показано, как использовать метрики и измерения задания Stream Analytics для анализа производительности задания с помощью портала Azure.
Предельная задержка и необработанные входные события — это основные метрики для определения производительности задания Stream Analytics. Если предельная задержка вашего задания постоянно увеличивается, а входные события остаются необработанными, это означает, что задание не в состоянии поддерживать скорость входных событий и своевременно создавать выходные данные.
Рассмотрим несколько примеров анализа производительности задания, используя в качестве отправной точки данные метрики Предельной задержки.
Отсутствие входных данных для определенной секции приводит к увеличению предельной задержки задания
Если предельная задержка чрезвычайно параллельного задания неуклонно увеличивается, перейдите к Метрикам. Затем выполните следующие действия, чтобы узнать, является ли первопричиной отсутствие данных в некоторых разделах входного источника:
Проверьте, какая секция характеризуется растущей предельной задержкой. Выберите метрику Предельной задержки и разделите ее по измерению идентификатора секции. В следующем примере секция 465 имеет высокую предельную задержку.
Проверьте, отсутствуют ли в секции какие-либо входные данные. Для этого можно выбрать метрику Входные события и отфильтровать ее по идентификатору этой секции.
Какие дальнейшие действия можно предпринять?
Предельная задержка для этой секции увеличивается, так как в эту секцию не поступают входные события. Если интервал поступления с задержкой для вашего задания составляет несколько часов, а в секцию не поступают входные данные, ожидается, что предельная задержка для этого раздела будет увеличиваться до тех пор, пока не будет достигнут допустимый интервал поступления с задержкой.
Например, если интервал поступления с задержкой составляет 6 часов, а входные данные не поступают во входную секцию 1, предельная задержка для выходной секции 1 будет увеличиваться, пока не достигнет 6 часов. Вы можете проверить, создает ли источник входных данных ожидаемые данные.
Неравномерное распределение входных данных приводит к высокой предельной задержке
Как упоминалось в предыдущем случае, когда у вашего чрезвычайно параллельного задания высокая предельная задержка, первое, что нужно сделать, — разделить метрику предельной задержки по измерению Идентификатора секции. Затем можно определить, имеют ли высокую предельную задержку все секции или лишь несколько из них.
В следующем примере секции 0 и 1 имеют более высокую предельную задержку (около 20–30 секунд), чем другие восемь секций. Предельная задержка в других секциях всегда стабильна и составляет 8–10 с.
Теперь проверим, как выглядят входные данные для всех этих секций, разделив метрику Входные события по Идентификатору секции:
Какие дальнейшие действия можно предпринять?
Как показано на снимке экрана выше, секции (0 и 1), в которых наблюдается высокая предельная задержка, получают значительно больше входных данных, чем другие секции. Мы называем это неравномерное распределение данных. Узлы потоковой передачи, обрабатывающие секции с неравномерным распределением данных, должны использовать больше ресурсов ЦП и памяти, чем другие, как показано на следующем снимке экрана.
Узлы потоковой передачи, обрабатывающие секции с более высоким распределением данных, будут иметь более высокую загрузку ЦП и (или) больше единиц потоковой передачи (SU). Такое использование повлияет на производительность задания и увеличит предельную задержку. Чтобы устранить эту проблему, вам потребуется перераспределить входные данные более равномерно.
Эту проблему также можно отлаживать с помощью схемы физических заданий. См. раздел Схема физических заданий. Определение неравномерно распределенных входных событий (неравномерное распределение данных).
Перегрузка ЦП или памяти увеличивает предельную задержку
Если чрезвычайно параллельное задание увеличивает предельную задержку, это может происходить не только в одной или нескольких, но и во всех секциях. Как подтвердить, что ваше задание — как раз такой случай?
Разделение метрики Предельной задержки по Идентификатору секции. Пример:
Разделите метрику Входные события в зависимости от Идентификатора секций, чтобы проверить, есть ли в каждой из секций неравномерное распределение входных данных.
Затем проверьте загрузку ЦП и памяти, чтобы узнать, не слишком ли высока загрузка во всех узлах потоковой передачи.
Если загрузка ЦП и памяти очень высокая (более 80 %) во всех узлах потоковой передачи, можно сделать вывод, что это задание имеет большой объем данных, обрабатываемых в каждом узле потоковой передачи.
Можно дополнительно проверить, сколько секций выделено одному узлу потоковой передачи, проверив метрику Событий ввода. Выполните фильтрацию по идентификатору узла потоковой передачи с измерением Имени узла и разделение по Идентификатору секции.
На предыдущем снимке экрана показано, что четыре секции назначены одному узлу потоковой передачи, который занимает около 90–100 процентов ресурса узла потоковой передачи. Вы можете использовать аналогичный подход для проверки остальных узлов потоковой передачи, чтобы убедиться, что они также обрабатывают данные четырех секций.
Какие дальнейшие действия можно предпринять?
Можно попробовать уменьшить количество разделов для каждого узла потоковой передачи, чтобы уменьшить объем входных данных для каждого узла потоковой передачи. Для этого следует в четыре раза повысить количество единиц, чтобы каждый узел потоковой передачи обрабатывал данные из двух секции. Кроме того, можно в четыре раза повысить количество единиц, чтобы каждый узел потоковой передачи обрабатывал данные из одной секции. Ознакомьтесь с разделом Обзор и настройка единиц потоковой передачи, где описана связь между назначением единиц хранения и числом узлов потоковой передачи.
Что делать, если предельная задержка по-прежнему увеличивается, когда один узел потоковой передачи обрабатывает данные одной секции? Перераспределите входные данные с использованием дополнительных секций, чтобы уменьшить объем данных в каждой секции. Дополнительные сведения см. в статье Использование повторного секционирования для оптимизации заданий Azure Stream Analytics.
Вы также можете отлаживать эту проблему с помощью схемы физических заданий, см. статью Схема физических заданий. Определение причины перегрузки ЦП или памяти.