Задача PythonOperator зависает при доступе к облачному хранилищу и укладывается в SCHEDULED - PullRequest
0 голосов
/ 28 июня 2018

Одна из задач в моей группе доступности баз данных иногда зависает при доступе к облачному хранилищу. Кажется, код останавливается на функции download здесь:

hook = GoogleCloudStorageHook(google_cloud_storage_conn_id='google_cloud_default') for input_file in hook.list(bucket, prefix=folder): hook.download(bucket=bucket, object=input_file)

В моих тестах папка содержит один файл json размером 20 МБ.

Задача обычно занимает 20-30 секунд, но в некоторых случаях она выполняется в течение 5 минут, после чего ее состояние обновляется до SCHEDULED и застревает там (ожидание более 6 часов). Я подозреваю, что 5 минут из-за конфигурации scheduler_zombie_task_threshold 300, но не уверен.

Если я очищаю задачу вручную в веб-интерфейсе, задача быстро ставится в очередь и снова запускается правильно. Я обошёл проблему, установив execution_timeout, который корректно обновляет задачу до состояния FAILED или UP_FOR_RETRY, если это занимает более 10 минут; но я хотел бы исправить основную проблему, чтобы избежать использования фиксированного порога времени ожидания, какие-либо предложения?

1 Ответ

0 голосов
/ 17 июля 2018

В группе Cloud Composer Discuss было обсуждение этого вопроса: https://groups.google.com/d/msg/cloud-composer-discuss/alnKzMjEj8Q/0lbp3bTlAgAJ. Это проблема с исполнителем Celery, когда умирают работники Airflow.

Хотя Composer работает над исправлением, если вы хотите, чтобы это происходило реже в текущей версии, вы можете рассмотреть возможность уменьшения конфигурации параллелизма Airflow или создания новой среды с большим типом машины.

...