#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.
В то же время, существует постоянный обходной путь, и его стоит попробовать. Вы должны выполнить эти шаги, чтобы ограничить загрузку процессора в модуле синхронизации:
- Перейдите на
environment configuration
страницу и нажмитеview cluster workloads
- Нажмите
airflow-scheduler
, затем отредактируйте - Найдите имя:
gcs-syncd
и добавьте:
resources:
limits:
cpu: some value (you can try with 300m)
requests:
cpu: 10m
затем нажмите save
(внизу).
- Повторите процедуру для airflow-worker.
- Мы также должны отредактировать раздел 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, поэтому я все еще чувствую, что здесь происходит что-то глючное.