【问题标题】:Airflow sigkill tasks on cloud composerCloud Composer 上的 Airflow sigkill 任务
【发布时间】:2021-10-10 18:15:38
【问题描述】:

我看到其他人提到过 sigkill,但我认为我的用例略有不同。

我正在通过 gcp cloud composer 使用托管气流服务,运行气流 2。我有 3 个工作节点都设置为默认实例创建设置。

该环境在大多数情况下运行得相当顺利(api 调用、从本地移动文件),但执行几个稍微大一点的作业似乎非常困难。

其中一个作业使用 samba 连接器以增量方式回填丢失的数据并存储在 gcs 上。另一个是 salesforce api 连接器。

这些作业在本地运行完全没有问题,所以我想知道为什么会遇到这些问题。应该有足够的内存来将这些任务作为一个集群来运行,尽管将我的集群扩展为仅 2 个作业似乎并不是特别有效。

我已经尝试过 dag 和任务超时。我已经尝试增加 samba 客户端的连接超时时间。

所以有人可以分享一些关于如何让气流在不终止会话的情况下执行这些任务的见解 - 即使它确实需要更长的时间。

如果需要,很高兴添加更多详细信息,但我目前没有可用的数据来分享。

【问题讨论】:

    标签: python airflow samba google-cloud-composer


    【解决方案1】:

    我相信这是关于连接上的保活。如果有长时间运行的呼叫导致长时间不活动(因为对方正忙于准备数据)。在托管实例上,非活动连接经常被防火墙杀死。例如,长 Postgres 查询和配置 keepalives 的解决方案会发生这种情况。

    我认为你应该为你的 samba 连接做同样的事情(但你需要弄清楚如何在 composer 中做到这一点)https://www.linuxtopia.org/online_books/network_administration_guides/using_samba_book/ch08_06_04.html

    【讨论】:

    • 我不知道这个。我会尝试配置,然后会回来。
    【解决方案2】:

    令人沮丧的是,增加资源意味着作业可以运行。我不知道为什么资源不够,因为它们本来应该是足够的。但是,除了增加成本之外,对完全托管的解决方案进行优化并不过分直接。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2022-11-11
      • 2019-07-21
      • 2019-02-20
      • 2021-02-22
      • 2020-07-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多