je viens de tomber sur un problème de ce genre. L'écoulement d'air consommait à peu près un vCPU complet dans un t2.xlarge instance, avec la grande majorité de cela venant du conteneur scheduler. En vérifiant les logs de l'ordonnanceur, je pouvais voir qu'il traitait mon dag unique plus d'une fois par seconde, même s'il ne tourne qu'une fois par jour. J'ai trouvé que MIN_FILE_PROCESS_INTERVAL était défini à la valeur par défaut de 0, donc le planificateur était en boucle sur le DAG. J'ai changé l'intervalle de processus à 65 secondes, et le flux D'Air utilise maintenant moins de 10 pour cent d'un vCPU dans un t2.moyenne instance.

j'ai également essayé tout ce que j'ai pu pour obtenir l'utilisation CPU bas et le Conseil de Matthew Housley concernant MIN_FILE_PROCESS_INTERVAL était ce qui a fait le tour.

au moins jusqu'à ce que l'airflow 1.10 arrive... puis L'utilisation du CPU est repartie à la hausse.

donc voici tout ce que j'ai eu à faire pour que airflow fonctionne bien sur une gouttelette océanique numérique standard avec 2 Go de ram et 1 vcpu:

1. Traitement Des Fichiers De L'Ordonnanceur

Empêcher le flux d'air recharger les dags tout le temps et régler: AIRFLOW__SCHEDULER__MIN_FILE_PROCESS_INTERVAL=60

2. Correction du bug de l'ordonnanceur de airflow 1.10

AIRFLOW-2895 bug dans airflow 1.10, provoque une charge CPU élevée, parce que l'ordonnanceur continue à Boucler sans interruption.

il est déjà fixé dans master et sera, espérons-le, inclus dans airflow 1.10.1, mais il pourrait prendre des semaines ou des mois avant sa sortie. En attendant ce correctif 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():

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

3. RBAC serveur web de charge élevée de l'UC

si vous avez mis à jour pour utiliser la nouvelle interface utilisateur RBAC, vous pouvez également remarquer que le serveur web utilise beaucoup de CPU de façon persistante.

pour une raison quelconque, L'interface RBAC utilise beaucoup de CPU au démarrage. Si vous utilisez un serveur de faible puissance, cela peut causer un démarrage très lent du serveur web et une utilisation élevée permanente du CPU.

j'ai documenté ce bug 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 Réglages, Mon flux d'air n'utilise que quelques % du CPU au ralenti sur une gouttelette numérique standard ocean avec 1 vcpu et 2 Go de ram.

essayez de changer 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

Pour commencer, vous pouvez utiliser htop pour surveiller et déboguer votre utilisation CPU.

je suggère que vous exécutiez les processus webserver et scheduler sur le même conteneur docker ce qui réduirait les ressources nécessaires pour exécuter deux conteneurs sur un ec2 t2.moyen. Les opérateurs de flux d'air ont besoin de ressources pour télécharger des données et les lire en mémoire, mais webserver et scheduler sont des processus assez légers. Assure que lorsque vous utilisez webserver vous contrôlez le nombre de les ouvriers qui travaillent sur l'instance en utilisant le 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]