Загрузка узла планировщика всегда превышает 100%

#airflow-scheduler #google-cloud-composer

#воздушный поток-планировщик #google-cloud-composer

Вопрос:

Мы запускаем Cloud Composer на 5 узлах, кластер n1-standard-2 запускает composer-1.11.3-airflow-1.10.9. Включен частный IP. Выбран Python 3. В настоящее время у нас есть около 30 баз данных, некоторые из которых содержат более 100 задач. Большинство баз данных выполняются один раз в день.

Узел, выполняющий airflow scheduler рабочую нагрузку, постоянно работает с загрузкой процессора около 150%, независимо от количества выполняемых задач. Единственный способ снизить загрузку ЦП — это удалять базы данных, пока не останется только 5 или 6 (очевидно, что это не вариант). Что мы пробовали:

  • Мы следили за этой статьей Medium, в которой подробно описывается, как запустить службу планировщика на выделенном узле, однако мы не можем найти конфигурацию, которая снижает загрузку процессора. Мы попробовали такой мощный узел, как e2-highcpu-32, работающий на твердотельном накопителе емкостью 100 ГБ. Загрузка осталась на уровне 150%.
  • Мы попытались обновить airflow.cfg переменные, чтобы уменьшить частоту, с которой dags анализируется каталог, с помощью таких настроек, как store_serialized_dags и max_threads . Опять же, это никак не повлияло на загрузку процессора.

Для справки, большую часть времени все остальные узлы работают с процессором 30-70%, а при работе с большими базами данных — более 100%. Ни у одного узла нет проблем с использованием памяти, при этом используется от 2 до 4 ГБ.

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

Редактировать в ответ на ответ Инес: я вижу загрузку процессора в процентах на Monitoring вкладке, узел, на котором запущена служба планировщика, окрашен в оранжевый цвет: введите описание изображения здесь Кроме того, когда я смотрю на запущенный модуль, airflow scheduler это загрузка процессора, почти всегда 100%: введите описание изображения здесь

Ответ №1:

Пожалуйста, ознакомьтесь с официальной документацией, которая описывает CPU usage per node метрику. Не могли бы вы уточнить, где вы видите процентные значения, поскольку в документации упоминается коэффициент использования основного времени:

Диаграмма, показывающая использование ядер ЦП, агрегированное по всем запущенным модулям в узле, измеренное как коэффициент использования основного времени. Сюда не входит загрузка процессора экземпляра App Engine, используемого для пользовательского интерфейса Airflow или экземпляра Cloud SQL. Высокая загрузка процессора часто является основной причиной выселения рабочих модулей. Если вы видите очень высокую загрузку, рассмотрите возможность масштабирования среды Composer или изменения расписания запусков DAG.

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

  1. Перейдите на environment configuration страницу и нажмите view cluster workloads
  2. Нажмите airflow-scheduler , затем отредактируйте
  3. Найдите имя: gcs-syncd и добавьте:
 resources:
  limits:
    cpu: some value (you can try with 300m)
  requests:
    cpu: 10m
  

затем нажмите save (внизу).

  1. Повторите процедуру для airflow-worker.
  2. Мы также должны отредактировать раздел airflow-планировщик рабочей нагрузки airflow-scheduler . Нажмите редактировать файл YAML и для раздела airflow-scheduler добавить:
 resources:
  limits:
    cpu: 750m
  requests:
    cpu: 300m
  

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

Иногда корзина /logs может состоять из большого количества файлов, что заставляет gcs-syncd сильно использовать процессор при выполнении внутренней синхронизации журналов. Вы можете попробовать удалить некоторые из самых старых журналов корзины gs://<composer-env-name>/logs . В качестве примера, если вы хотите удалить все журналы May, пожалуйста, используйте следующую команду:

 gsutil -m rm -r gs://europe-west1-td2-composter-a438b8eb-bucket/logs/*/*/2020-05*
  

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

Комментарии:

1. Спасибо @ines, я отредактировал свой вопрос, чтобы предоставить больше информации, я постараюсь следовать вашим рекомендованным шагам.

2. Да, я выполнил предложенные вами шаги. Если я правильно их понимаю, эти шаги выделяют меньше ресурсов для синхронизации GCS и больше ресурсов для планировщика. Это привело к незначительному снижению загрузки процессора (на Monitoring вкладке) до ~ 120%. Я не уверен, что это напрямую отвечает на вопрос, который я задал, я бы предпочел, чтобы загрузка процессора составляла <90%, редактируя расписание синтаксического анализа dagbag, а не ограничивая ресурсы. Наличие узла, работающего более чем на 100%, никогда не было проблемой с предыдущими версиями Composer, поэтому я все еще чувствую, что здесь происходит что-то глючное.