0
366
VistasAirbnb Airflow utilizando todos los recursos del sistema
Configuramos Airbnb/Apache Airflow para nuestro ETL usando LocalExecutor y, a medida que comenzamos a crear DAG más complejos, notamos que Airflow comenzó a consumir cantidades increíbles de recursos del sistema. Esto nos sorprende porque usamos Airflow principalmente para orquestar tareas que ocurren en otros servidores, por lo que los DAG de Airflow pasan la mayor parte del tiempo esperando 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 2 GB de memoria con la configuración predeterminada de airflow.cfg.
Si es relevante, estamos ejecutando Airflow usando 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 (dado que ese parece ser el problema principal ahora, tengo la CPU inactiva): 
Supongo que, en teoría, podría reducir la cantidad de trabajadores de gunicorn (el valor predeterminado es 4), pero no estoy seguro de cuáles son todos los procesos de /usr/bin/dockerd . Si Docker está complicando las cosas, podría eliminarlo, pero ha hecho que la implementación de cambios sea realmente fácil y prefiero no eliminarlo si es posible.
3 Respuestas
Responde la pregunta0
También intenté 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 funcionó.
Al menos hasta que llegó Airflow 1.10... entonces el uso de la CPU se disparó de nuevo.
Entonces, aquí está todo lo que tuve que hacer para que el flujo de aire funcionara bien en una gota de agua digital estándar con 2 gb de ram y 1 vcpu:
1. Procesamiento de archivos del programador
Evite que el flujo de aire recargue los dags todo el tiempo y configure: AIRFLOW__SCHEDULER__MIN_FILE_PROCESS_INTERVAL=60
2. Arreglar el error del programador de flujo de aire 1.10
El error AIRFLOW-2895 en airflow 1.10 provoca una alta carga de la CPU, porque el programador sigue en bucle sin interrupción.
Ya está corregido en el maestro y, con suerte, se incluirá en airflow 1.10.1, pero podrían pasar semanas o meses hasta que se publique. 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. Alta carga de CPU del servidor web RBAC
Si actualizó para usar la nueva interfaz de usuario del servidor web RBAC, también puede notar que el servidor web está usando una gran cantidad de CPU de manera persistente.
Por alguna razón, la interfaz RBAC usa mucha CPU en el inicio. Si está ejecutando en un servidor de baja potencia, esto puede causar un inicio muy lento del servidor web y un uso de CPU permanentemente alto.
He documentado este error como AIRFLOW-3037 . Para solucionarlo 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 2minCon todos estos ajustes, mi flujo de aire usa solo un pequeño % de la CPU durante el tiempo de inactividad en una gota estándar del océano digital con 1 vcpu y 2 gb de ram.
0
Acabo de encontrarme con un problema como este. Airflow consumía aproximadamente una vCPU completa en una instancia t2.xlarge, y la gran mayoría provenía del contenedor del programador. Al revisar los registros del programador, pude ver que estaba procesando mi único DAG más de una vez por segundo a pesar de que solo se ejecuta una vez al día.
Descubrí que MIN_FILE_PROCESS_INTERVAL se estableció en el valor predeterminado de 0 , por lo que el programador estaba recorriendo el DAG. Cambié el intervalo del proceso a 65 segundos y Airflow ahora usa menos del 10 por ciento de una vCPU en una instancia t2.medium.
0
Intente 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