#python #airflow-scheduler #airflow
#python #воздушный поток-планировщик #воздушный поток
Вопрос:
Версия Airflow = 1.10.10
Размещен на Kubernetes, использует Kubernetes executor.
Настройка DAG
DAG — генерируется с использованием динамической базы данных
Task — это PythonOperator, который извлекает некоторые данные, выполняет вывод, сохраняет прогнозы.
Где он зависает? — При выполнении вывода с использованием tensorflow
Подробнее
Одна из наших запущенных задач, как упоминалось выше, зависала в течение 4 часов. Никакой перезапуск не может помочь ему восстановиться с этой точки. Мы обнаружили, что в модуле было более 30 подпроцессов и 40 ГБ используемой памяти.
Мы не были убеждены, потому что при запуске на локальной машине модель не потребляет более 400 МБ. Невозможно, чтобы он внезапно увеличил объем памяти до 40 ГБ.
Другое подозрение заключалось в том, что, возможно, он запускает так много процессов, потому что мы динамически генерируем около 19 баз данных. Я изменил генератор, чтобы генерировать только 1, и процессы не исчезли. У рабочих модулей по-прежнему было более 35 подпроцессов с той же памятью.
Здесь начинается интересная часть, я хотел быть действительно уверенным, что это не динамический DAG. Поэтому я создал независимую базу данных, которая выводит 1 ..100000, делая паузу на 5 секунд каждый. Использование памяти осталось прежним, но не количество процессов.
На данный момент я не уверен, в каком направлении двигаться для дальнейшей отладки проблемы.
Вопросы
- Почему задача зависает?
- Почему при использовании динамического dag так много подпроцессов?
- Как я могу отладить эту проблему дальше?
- Сталкивались ли вы с этим раньше и можете ли вы помочь?