Airbnb Airflow с использованием всех системных ресурсов

Мы создали Airbnb/Apache Airflow для нашего ETL, используя LocalExecutor, и по мере того, как мы начали создавать более сложные группы DAG, мы заметили, что Airflow начинает использовать невероятные объемы системных ресурсов. Это удивительно для нас, потому что мы в основном используем Airflow для организации задач, которые происходят на других серверах, поэтому DAG для Airflow проводят большую часть своего времени, ожидая их завершения, - нет реального выполнения, которое происходит локально.

Самая большая проблема заключается в том, что Airflow все время использует до 100% процессора (на AWS t2.medium) и использует более 2 ГБ памяти с настройками по умолчанию airflow.cfg.

Если это уместно, мы запускаем Airflow, используя docker-compose, запускающую контейнер дважды; один раз как scheduler и один раз как webserver.

Что мы делаем неправильно здесь? Это нормально?

EDIT: Вот результат из htop, упорядоченный по используемой памяти% (поскольку это, похоже, сейчас является основной проблемой, я потерял CPU):

Я полагаю, что в теории я мог бы уменьшить количество рабочих-пулеметов (это было по умолчанию 4), но я не уверен, что все процессы /usr/bin/dockerd. Если Docker усложняет то, что я могу удалить, но это сделало развертывание изменений очень легким, и я предпочел бы не удалять его, если это возможно.

Ответ 1

Я также перепробовал все, что мог, чтобы снизить нагрузку на процессор, и совет Мэттью Хаусли относительно MIN_FILE_PROCESS_INTERVAL был тем, что сработало.

По крайней мере, до тех пор, пока не возникнет поток воздуха 1.10... затем загрузка процессора снова пошла вверх.

Итак, вот все, что мне нужно было сделать, чтобы поток воздуха работал на стандартной цифровой океанской капле с 2 ГБ оперативной памяти и 1 виртуальным процессором:

1. Обработка файлов планировщика

Предотвратите постоянную перегрузку воздушных потоков и установите: AIRFLOW__SCHEDULER__MIN_FILE_PROCESS_INTERVAL=60

2. Исправить ошибку в планировщике воздушного потока 1.10

Ошибка AIRFLOW-2895 в потоке воздуха 1.10 приводит к высокой загрузке процессора, поскольку планировщик продолжает цикл без перерыва.

Он уже исправлен в master и, как мы надеемся, будет включен в airflow 1.10.1, но это может занять несколько недель или месяцев до его выпуска. Тем временем этот патч решает проблему:

--- jobs.py.orig    2018-09-08 15:55:03.448834310 +0000
+++ jobs.py     2018-09-08 15:57:02.847751035 +0000
@@ -564,6 +564,7 @@

         self.num_runs = num_runs
         self.run_duration = run_duration
+        self._processor_poll_interval = 1.0

         self.do_pickle = do_pickle
         super(SchedulerJob, self).__init__(*args, **kwargs)
@@ -1724,6 +1725,8 @@
             loop_end_time = time.time()
             self.log.debug("Ran scheduling loop in %.2f seconds",
                            loop_end_time - loop_start_time)
+            self.log.debug("Sleeping for %.2f seconds", self._processor_poll_interval)
+            time.sleep(self._processor_poll_interval)

             # Exit early for a test mode
             if processor_manager.max_runs_reached():

Примените его с patch -d /usr/local/lib/python3.6/site-packages/airflow/ < af_1.10_high_cpu.patch;

3. Высокая загрузка процессора веб-сервером RBAC

Если вы перешли на новый пользовательский интерфейс веб-сервера RBAC, вы также можете заметить, что веб-сервер постоянно использует много ЦП.

По какой-то причине интерфейс RBAC использует много CPU при запуске. Если вы работаете на маломощном сервере, это может привести к очень медленному запуску веб-сервера и постоянно высокой загрузке ЦП.

Я задокументировал эту ошибку как AIRFLOW-3037. Для ее решения вы можете настроить конфиг:

AIRFLOW__WEBSERVER__WORKERS=2 # 2 * NUM_CPU_CORES + 1
AIRFLOW__WEBSERVER__WORKER_REFRESH_INTERVAL=1800 # Restart workers every 30min instead of 30seconds
AIRFLOW__WEBSERVER__WEB_SERVER_WORKER_TIMEOUT=300 #Kill workers if they don't start within 5min instead of 2min

Со всеми этими настройками мой воздушный поток использует только несколько% процессорного времени во время простоя на стандартной цифровой капельке океана с 1 vcpu и 2 ГБ оперативной памяти.

Ответ 2

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

Я обнаружил, что для MIN_FILE_PROCESS_INTERVAL было установлено значение по умолчанию 0, поэтому планировщик зацикливался на DAG. Я изменил интервал процесса на 65 секунд, и теперь Airflow использует менее 10 процентов виртуального ЦП в экземпляре t2.medium.

Ответ 3

Попробуйте изменить приведенный ниже конфиг в airflow.cfg

# after how much time a new DAGs should be picked up from the filesystem
min_file_process_interval = 0

# How many seconds to wait between file-parsing loops to prevent the logs from being spammed.
min_file_parsing_loop_time = 1

Ответ 4

Для начала вы можете использовать htop для мониторинга и отладки вашего использования ЦП.

Я бы предположил, что вы запускаете процессы webserver и scheduler в одном контейнере докеров, что уменьшит ресурсы, необходимые для запуска двух контейнеров на ec2 t2.medium. Работники Airflow нуждаются в ресурсах для загрузки данных и чтения их в памяти, но веб-сервер и планировщик - довольно легкие процессы. Уверен, что при запуске веб-сервера вы контролируете количество рабочих, работающих в экземпляре, используя cli.

airflow webserver [-h] [-p PORT] [-w WORKERS]
                         [-k {sync,eventlet,gevent,tornado}]
                         [-t WORKER_TIMEOUT] [-hn HOSTNAME] [--pid [PID]] [-D]
                         [--stdout STDOUT] [--stderr STDERR]
                         [-A ACCESS_LOGFILE] [-E ERROR_LOGFILE] [-l LOG_FILE]
                         [-d]