web-dev-qa-db-fra.com

Airbnb Airflow utilisant toutes les ressources du système

Nous avons configuré Airbnb/Apache Airflow pour notre ETL à l'aide de LocalExecutor, et comme nous avons commencé à créer des DAG plus complexes, nous avons remarqué qu'Airflow commençait à utiliser des quantités incroyables de ressources système. Cela nous surprend car nous utilisons principalement Airflow pour orchestrer les tâches qui se produisent sur d'autres serveurs, de sorte que les DAG Airflow passent la plupart de leur temps à les attendre - aucune exécution réelle ne se produit localement.

Le plus gros problème est qu'Airflow semble utiliser 100% du processeur à tout moment (sur un AWS t2.medium) et utilise plus de 2 Go de mémoire avec les paramètres airflow.cfg par défaut.

Le cas échéant, nous exécutons Airflow à l'aide de docker-compose exécutant le conteneur deux fois; une fois comme scheduler et une fois comme webserver.

Que faisons-nous de mal ici? Est-ce normal?

EDIT: Voici la sortie de htop, ordonnée par% Memory used (puisque cela semble être le problème principal maintenant, j'ai eu CPU en panne): HtopHtop2

Je suppose qu'en théorie, je pourrais réduire le nombre de travailleurs de la licorne (c'est la valeur par défaut de 4), mais je ne sais pas ce que tous les /usr/bin/dockerd les processus le sont. Si Docker complique les choses, je pourrais le supprimer, mais cela a rendu le déploiement des modifications très facile et je préfère ne pas le supprimer si possible.

dockeramazon-ec2airflow
31
jdotjdot

J'ai également essayé tout ce que je pouvais pour réduire l'utilisation du processeur et les conseils de Matthew Housley concernant MIN_FILE_PROCESS_INTERVAL ont fait l'affaire.

Au moins jusqu'à ce que le flux d'air 1.10 apparaisse ... puis l'utilisation du processeur est remontée.

Voici donc tout ce que je devais faire pour que le flux d'air fonctionne correctement sur une gouttelette d'océan numérique standard avec 2 Go de RAM et 1 processeur virtuel:

1. Traitement des fichiers du planificateur

Empêchez l'airflow de recharger les dags tout le temps et définissez: AIRFLOW__SCHEDULER__MIN_FILE_PROCESS_INTERVAL=60

2. Correction du bug du planificateur airflow 1.10

Le bogue AIRFLOW-2895 dans airflow 1.10, entraîne une charge CPU élevée, car le planificateur continue de boucler sans interruption.

Il est déjà corrigé dans master et devrait être inclus dans airflow 1.10.1, mais cela pourrait prendre des semaines ou des mois avant sa sortie. En attendant, ce patch résout le problème:

--- 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():

Appliquez-le avec patch -d /usr/local/lib/python3.6/site-packages/airflow/ < af_1.10_high_cpu.patch;

3. Charge élevée du processeur du serveur Web RBAC

Si vous avez effectué une mise à niveau pour utiliser la nouvelle interface utilisateur du serveur Web RBAC, vous remarquerez peut-être également que le serveur Web utilise beaucoup de CPU de manière persistante.

Pour une raison quelconque, l'interface RBAC utilise beaucoup de CPU au démarrage. Si vous exécutez sur un serveur de faible puissance, cela peut entraîner un démarrage très lent du serveur Web et une utilisation du processeur élevée en permanence.

J'ai documenté ce bogue comme AIRFLOW-3037 . Pour le résoudre, vous pouvez ajuster la configuration:

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

Avec tous ces ajustements, mon flux d'air n'utilise que quelques% du processeur pendant le temps d'inactivité sur une gouttelette standard Digital Ocean avec 1 processeur virtuel et 2 Go de RAM.

25
user3505886

Je viens de rencontrer un problème comme celui-ci. Airflow consommait à peu près un vCPU complet dans une instance t2.xlarge, la grande majorité provenant du conteneur du planificateur. En vérifiant les journaux du planificateur, j'ai pu voir qu'il traitait mon seul DAG plus d'une fois par seconde, même s'il ne fonctionne qu'une fois par jour. J'ai trouvé que MIN_FILE_PROCESS_INTERVAL était réglé sur la valeur par défaut de 0, donc le planificateur faisait une boucle sur le DAG. J'ai modifié l'intervalle de processus à 65 secondes et Airflow utilise désormais moins de 10% d'un processeur virtuel dans une instance t2.medium.

16
Matthew Housley

Essayez de modifier la configuration ci-dessous dans 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

Pour commencer, vous pouvez utiliser htop pour surveiller et déboguer l'utilisation de votre processeur.

Je suggère que vous exécutiez des processus de serveur Web et de planificateur sur le même conteneur Docker, ce qui réduirait les ressources requises pour exécuter deux conteneurs sur un ec2 t2.medium. Les employés d'Airflow ont besoin de ressources pour télécharger des données et les lire en mémoire, mais le serveur Web et le planificateur sont des processus assez légers. S'assure que lorsque vous exécutez le serveur Web, vous contrôlez le nombre de travailleurs exécutés sur l'instance à l'aide de la 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