Инициализация задачи DAG требует времени - PullRequest
0 голосов
/ 28 мая 2020

У нас есть среда composer, конфигурация которой приведена ниже.

  • Composer Версия: composer -1.10.0-airflow-1.10.6
  • Тип машины: n1-standard-4
  • Размер диска ( ГБ): 100
  • Рабочие узлы: 6
  • python версия: 3
  • worker_concurrency: 32
  • параллелизм: 128

У нас есть проблема в DAG с инициализацией этой задачи, и это занимает больше времени. Например, у DAG есть 3 задачи, такие как Task1 -> Task2 -> Task3. Task1 инициализирует время выполнения (минимум 5 минут) и единожды инициализированное время завершения этой задачи в секундах. Инициализация Task2 снова занимает 5 минут и выполняется в течение нескольких секунд. Как будто инициализация этой задачи требует времени, но завершение этой задачи выполняется быстро. Запланируйте этот DAG каждые 5 минут, но его выполнение занимает не менее 10 минут. Это влияет на функциональность и выполнение процесса.

Вот функциональные возможности каждой из трех задач. Задача Task1 - собрать основную c информацию, такую ​​как место хранения, из файлов / переменных конфигурации. Task2 проверяет хранилище, поступают ли новые файлы, и на основе файла запускает соответствующие группы DAG. Задача Task3 - отправить сообщение об успешном выполнении.

Также я заметил, что рабочие узлы не разделяли работу между собой. Использование ЦП одного рабочего узла всегда выше по сравнению с другими рабочими узлами. Не знаю, в чем может быть причина. Еще один интересный момент: хотя другие группы DAG в это время не работают, выполнение этой группы DAG все еще занимает 10 минут.

Благодарен за вашу помощь в решении этого случая.

Ответы [ 2 ]

1 голос
/ 29 мая 2020

Это должен быть комментарий, но у меня нет требуемой репутации.

Мой первый совет - обновить вашу Composer версию, в 1.10.0 есть несколько известных ошибок которые исправлены в более поздних версиях. На данный момент последняя версия - 1.10.4. Это должно исправить процессор, который остается на 100% (в нашем случае так и было). На вашем экземпляре работает много других DAG?

0 голосов
/ 04 июня 2020

Как я упоминал в комментарии, причина высокой нагрузки на ЦП на конкретном узле GKE может быть более очевидной после устранения неполадок, выполненных на Рабочий процесс воздушного потока / GKE сторон.

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

Согласно GCP Composer примечания к выпуску , поставщик предоставил некоторые важные исправления в последних composer-1.10.* патчах, улучшив производительность и надежность Composer времени выполнения, как сказал @parakeet в h - это ответ.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...