remove - docker run
Airbnb Airflow utilizando todos los recursos del sistema (4)
Acabo de encontrar un problema como este. El flujo de aire consumía aproximadamente una vCPU completa en una instancia de t2.xlarge, con la gran mayoría de esto proveniente del contenedor del programador. Al revisar los registros del programador, pude ver que estaba procesando mi solo DAG más de una vez por segundo a pesar de que solo se ejecuta una vez al día. Encontré que el MIN_FILE_PROCESS_INTERVAL se configuró en el valor predeterminado de 0, por lo que el programador estaba haciendo un bucle en el DAG. Cambié el intervalo de proceso a 65 segundos, y Airflow ahora usa menos del 10 por ciento de una vCPU en una instancia de t2.medium.
Hemos configurado Airbnb / Apache Airflow para nuestra ETL utilizando LocalExecutor y, a medida que comenzamos a crear DAG más complejos, hemos notado que Airflow está empezando a utilizar cantidades increíbles de recursos del sistema. Esto nos sorprende porque utilizamos principalmente Airflow para organizar tareas que ocurren en otros servidores, por lo que los DAG de Airflow pasan la mayor parte del tiempo esperando a que se completen, no hay una ejecución real que ocurra localmente.
El mayor problema es que Airflow parece usar el 100% de la CPU en todo momento (en un AWS t2.medium), y usa más de 2GB de memoria con la configuración predeterminada de airflow.cfg.
Si es relevante, estamos ejecutando Airflow utilizando la función docker-compose ejecutando el contenedor dos veces; Una vez como scheduler y una vez como webserver .
¿Qué estamos haciendo mal aquí? ¿Esto es normal?
EDITAR: Aquí está la salida de htop , ordenada por% de memoria utilizada (ya que parece ser el problema principal ahora, tengo la CPU baja):
Supongo que, en teoría, podría reducir el número de trabajadores de Gunicorn (tiene un valor predeterminado de 4), pero no estoy seguro de cuáles son todos los procesos /usr/bin/dockerd . Si Docker está complicando las cosas, podría eliminarlo, pero hizo que la implementación de cambios fuera realmente fácil y preferiría no eliminarlo si es posible.
Intenta cambiar la siguiente configuración en 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
Para empezar, puedes usar htop para monitorear y depurar el uso de tu CPU.
Le sugiero que ejecute los procesos del servidor web y del programador en el mismo contenedor de la ventana acoplable, lo que reduciría los recursos necesarios para ejecutar dos contenedores en un EC2 t2.medium. Los trabajadores de flujo de aire necesitan recursos para descargar datos y leerlos en la memoria, pero el servidor web y el programador son procesos bastante ligeros. Se asegura de que cuando ejecuta el servidor web, está controlando el número de trabajadores que se ejecutan en la instancia utilizando el 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]
También he intentado todo lo que pude para reducir el uso de la CPU y el consejo de Matthew Housley con respecto a MIN_FILE_PROCESS_INTERVAL fue lo que hizo el truco.
Al menos hasta que el flujo de aire 1.10 apareciera ... luego, el uso de la CPU pasó de nuevo por el techo.
Así que aquí está todo lo que tenía que hacer para que el flujo de aire funcionara bien en una gota de océano digital estándar con 2 gb de ram y 1 vcpu:
1. Procesador de archivos del programador
Evite que el flujo de aire vuelva a cargar los dags todo el tiempo y establezca: AIRFLOW__SCHEDULER__MIN_FILE_PROCESS_INTERVAL=60
2. Arreglar el error del programador del flujo de aire 1.10
El error AIRFLOW-2895 en el flujo de aire 1.10, causa una alta carga de la CPU, porque el programador continúa en bucle sin interrupciones.
Ya está arreglado en la versión maestra y es de esperar que se incluya en el flujo de aire 1.10.1, pero podría llevar semanas o meses hasta su lanzamiento. Mientras tanto, este parche resuelve el problema:
--- 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():
Aplíquelo con el patch -d /usr/local/lib/python3.6/site-packages/airflow/ < af_1.10_high_cpu.patch;
3. RBAC webserver alta carga de CPU
Si actualizó para usar la nueva interfaz de usuario del servidor web RBAC, también puede notar que el servidor web está utilizando una gran cantidad de CPU de forma persistente.
Por alguna razón, la interfaz RBAC usa una gran cantidad de CPU al inicio. Si está ejecutando en un servidor de baja potencia, esto puede provocar un inicio muy lento del servidor web y un uso de la CPU permanentemente alto.
He documentado este error como AIRFLOW-3037 . Para resolverlo puedes ajustar la configuración:
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
Con todos estos ajustes, mi flujo de aire está usando solo un pequeño% de CPU durante el tiempo de inactividad en una gota estándar oceánica digital con 1 vcpu y 2 gb de ram.