web-dev-qa-db-ja.com

すべてのシステムリソースを使用するAirbnb Airflow

LocalExecutorを使用してETLにAirbnb/Apache Airflowを設定しました。さらに複雑なDAGの構築を開始すると、Airflowが信じられないほどのシステムリソースを使用し始めていることに気付きました。ほとんどの場合、Airflowを使用して他のサーバーで発生するタスクを調整するため、これは驚くべきことです。そのため、Airflow DAGは、完了するまで待つことにほとんどの時間を費やしています。実際にローカルで実行される実行はありません。

最大の問題は、Airflowが常にCPUを100％使用しているように見える（AWS t2.medium上）ようであり、デフォルトのairflow.cfg設定で2GBを超えるメモリを使用することです。

関連する場合は、コンテナを2回実行するdocker-composeを使用してAirflowを実行しています。 1回はschedulerとして、もう1回はwebserverとして。

ここで何が間違っていますか？これは正常ですか？

EDIT：これは、htopからの出力で、使用されているメモリの割合で並べられています（これが主な問題であると思われるため、 CPUダウン）： HtopHtop2

理論的にはgunicornワーカーの数を減らすことができると思います（デフォルトは4です）が、すべての/usr/bin/dockerdプロセスがあります。 Dockerが問題を複雑にしている場合は削除できますが、変更の展開が非常に簡単になり、可能であれば削除しない方がいいでしょう。

dockeramazon-ec2airflow
31
jdotjdot

また、CPU使用率を下げるためにできる限りのことを試しましたが、MIN_FILE_PROCESS_INTERVALに関するMatthew Housleyのアドバイスは、このトリックを実行したものです。

少なくとも気流1.10が発生するまで...その後、CPU使用率は再び屋根を通りました。

そこで、2GBのRAMと1つのvcpuを備えた標準のデジタルオーシャンドロップでエアフローをうまく機能させるために必要なすべてを以下に示します。

1.スケジューラファイル処理

エアフローが常にDAGをリロードしないように設定します：AIRFLOW__SCHEDULER__MIN_FILE_PROCESS_INTERVAL=60

2.エアフロー1.10スケジューラーのバグを修正

エアフロー1.10の AIRFLOW-2895 バグは、スケジューラーが途切れることなくループを続けるため、CPUの負荷が高くなります。

マスターで既に修正されており、エアフロー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 WebサーバーのCPU負荷が高い

新しいRBAC WebサーバーUIを使用するようにアップグレードした場合、Webサーバーが多くのCPUを永続的に使用していることにも気付くかもしれません。

何らかの理由で、RBACインターフェイスは起動時に多くのCPUを使用します。低電力のサーバーで実行している場合、これによりWebサーバーの起動が非常に遅くなり、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ギガバイトのRAMを備えたDigital Ocean標準ドロップレットのアイドル時間中に、私の気流はCPUの数％しか使用しません。

25
user3505886

私はこのような問題に遭遇しました。 Airflowは、t2.xlargeインスタンスでほぼ完全なvCPUを消費していましたが、その大半はスケジューラコンテナからのものでした。スケジューラログを確認すると、1日1回しか実行されていなくても、1つのDAGが1秒に1回以上処理されていることがわかりました。 MIN_FILE_PROCESS_INTERVALがデフォルト値の0に設定されているため、スケジューラはDAGをループしていました。プロセス間隔を65秒に変更すると、Airflowはt2.mediumインスタンスでvCPUの10％未満を使用するようになりました。

16
Matthew Housley

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
2
feng ce

まず、 htop を使用してCPU使用率を監視およびデバッグできます。

同じドッカーコンテナでWebサーバーとスケジューラプロセスを実行することをお勧めします。これにより、ec2 t2.mediumで2つのコンテナを実行するために必要なリソースが削減されます。エアフローワーカーは、データをダウンロードしてメモリで読み取るためのリソースを必要としますが、ウェブサーバーとスケジューラは非常に軽量なプロセスです。 Webサーバーを実行するときに、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]
0
nehiljain