Устраняйте неполадок в эффективности работы Stream Analytics с помощью метрик и измерений

Чтобы понять состояние работы в Azure Stream Analytics, необходимо уметь использовать метрики и измерения работы. Интересующие вас метрики и измерения можно получить через портал Azure, расширение Visual Studio Code Stream Analytics или SDK.

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

В этой статье показано, как использовать метрики и измерения задания Stream Analytics в портале Azure для устранения неполадок, связанных с производительностью задания. В следующих разделах рассматриваются несколько примеров, в которых в качестве отправной точки используется метрика Watermark Delay, для диагностики распространённых проблем с производительностью.

Отсутствие входных данных для определенной секции приводит к увеличению предельной задержки задания

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

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

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

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

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

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

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

Неравномерное распределение входных данных приводит к высокой предельной задержке

Если у вашей крайне распараллеливаемой задачи наблюдается высокая задержка водяного знака, сначала разбейте метрику Watermark Delay по параметру Partition ID. Затем определите, наблюдается ли высокая задержка по high watermark у всех разделов или только у некоторых.

В следующем примере разделы 0 и 1 имеют большую задержку водяного знака (около 20–30 секунд), чем остальные восемь разделов. Задержки watermark в остальных разделах всегда остаются стабильными — около 8–10 с.

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

Проверьте, как выглядят входные данные между этими разделами, разделив метрику Input Events на идентификатор раздела:

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

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

Снимок экрана: схема, показывающая использование ресурсов в секциях с неравномерным распределением данных.

Потоковые узлы, обрабатывающие разделы с более сильным перекосом данных, демонстрируют более высокую загрузку ЦП, % и использование SU (память), %. Эта нагрузка на ресурсы влияет на производительность задания и увеличивает задержку водяных знаков. Чтобы смягчить проблему, переразбийте входные данные более равномерно.

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

Перегрузка ЦП или памяти увеличивает предельную задержку

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

  1. Разделение метрики Предельной задержки по Идентификатору секции. Например:

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

  2. Разделите метрику Input Events на Partition ID , чтобы убедиться, есть ли смещение данных в входных данных для каждого раздела.

  3. Проверьте метрики CPU % Utilization и SU (Memory) % Utilization , чтобы узнать, не слишком ли высокая загрузка во всех потоковых узлах.

    Снимок экрана: схема, показывающая использование ЦП и памяти в разбивке по имени узла в случае перегрузки ЦП и памяти.

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

    Проверьте, сколько разделов выделено одному потоковому узлу, используя метрику Input Events . Выполните фильтрацию по идентификатору узла потоковой передачи с измерением Имени узла и разделение по Идентификатору секции.

    Снимок экрана: схема, показывающая количество секций на одном узле потоковой передачи в случае перегрузки ЦП и памяти.

  5. На предыдущем снимке экрана показано, что четыре секции назначены одному узлу потоковой передачи, который занимает около 90–100 процентов ресурса узла потоковой передачи. Используйте похожий подход, чтобы проверить остальные потоковые узлы и убедиться, что они тоже обрабатывают данные из четырёх разделов.

Уменьшить количество разделов, которые обрабатывает каждый потоковый узел для уменьшения входных данных на узел. Для этого удвойте количество SU, чтобы каждый потоковый узел обрабатывал данные из двух разделов, или учетверьте количество SU, чтобы каждый потоковый узел обрабатывал данные из одного раздела. Сведения о связи между назначением SU и числом узлов потоковой передачи см. в разделе Описание и настройка единиц потоковой передачи.

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

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

Связанные материалы

  • Last updated on