根据这两个 Link1 和 Link2，由于内存不足问题，我的 Airflow DAG 运行INFO - Task exited with return code -9返回错误。我的 DAG 运行有 10 个任务/运算符，每个任务都很简单：
- 进行查询以获取我的一个 BigQuery 表，并且
- 将结果写入我的 Mongo 数据库中的集合。
10 个 BigQuery 表的大小范围从 1MB 到 400MB，所有 10 个表的总大小为 ~1GB。我的 docker 容器具有默认的 2GB 内存，我已将其增加到 4GB，但是我仍然从一些任务中收到此错误。我对此感到困惑，因为 4GB 应该有足够的内存。我也担心，因为将来这些表可能会变大(单个表查询可能是 1-2GB(，我想在那个时候避免这些return code -9错误。
我不太确定如何处理这个问题，因为 DAG 的目的是每天将数据从 BigQuery 传输到 Mongo，并且 DAG 任务的内存中的查询/数据必然相当大，具体取决于表的大小。
正如您所说，您收到的错误消息对应于内存不足问题。
参考官方文档：
DAG 执行受 RAM 限制。每个任务执行从两个开始 气流过程：任务执行和监控。目前，每个节点 最多可以执行 6 个并发任务。可以消耗更多内存， 取决于 DAG 的大小。
任何 GKE 节点中的高内存压力都会导致 Kubernetes 调度程序从节点中驱逐 pod，以试图缓解这种压力。虽然许多不同的 Airflow 组件在 GKE 中运行，但大多数组件往往不会使用太多内存，因此最常发生的情况是用户上传了资源密集型 DAG。Airflow 工作线程运行这些 DAG，耗尽资源，然后被逐出。
您可以通过以下步骤进行检查：
-
在云控制台中，导航到
Kubernetes Engine->Workloads -
单击"
airflow-worker"，然后在"Managed pods -
如果存在显示
Evicted的容器，请单击每个逐出的容器，然后在窗口顶部查找The node was low on resource: memory消息。
修复 OOM 问题的可能方法是什么？
- 创建一个新的云编排环境，其计算机类型大于当前计算机类型。
- 确保 DAG 中的任务是幂等的，这意味着多次运行同一 DAG 的结果应与运行一次的结果相同。
- 通过设置任务的重试次数来配置任务重试次数 - 这样，当您的任务被调度程序
-9'ed时，它将转到up_for_retry而不是failed
此外，您还可以检查 CPU 的行为：
- 在云控制台中，导航到
Kubernetes Engine->Clusters - 找到页面底部的
Node Pools，然后展开"default-pool"部分 - 单击"
Instance groups"下列出的链接 - 切换到"
Monitoring"选项卡，您可以在其中找到CPU utilization
理想情况下，GCE 实例不应始终运行超过 70% 的 CPU，否则 Composer 环境可能会在资源使用期间变得不稳定。
我希望您发现上述信息有用。
我将对数据进行分块，以便在任何给定时间加载到任何 1 个任务中的数量更少。我还不确定我是否需要使用 GCS/S3 进行中间存储。