调试内存不足和存储空间不足的 DAG 问题

Cloud Composer 1 | Cloud Composer 2

本教程介绍了如何借助日志和环境监控在 Cloud Composer 中调试失败的 Airflow DAG,并诊断与工作器资源相关的问题,例如工作器内存不足或存储空间不足。

简介

本教程重点介绍资源相关问题,以演示调试 DAG 的方法。

分配的工作器资源不足会导致 DAG 故障。如果 Airflow 任务耗尽内存或存储空间,您可能会看到 Airflow 异常,例如:

WARNING airflow.exceptions.AirflowException: Task received SIGTERM signal
INFO - Marking task as FAILED.

Task exited with return code Negsignal.SIGKILL

在这种情况下,一般建议是增加 Airflow 工作器资源或减少每个工作器的任务数。但是,由于 Airflow 异常可能是通用的,因此可能很难找出导致问题的特定资源。

本教程介绍如何通过调试因工作器内存和存储空间不足而失败的两个示例 DAG 来诊断 DAG 失败的原因,并确定导致问题的资源类型。

目标

  • 运行由于以下原因而失败的示例 DAG:

    • 工作器内存不足
    • 工作器存储空间不足
  • 诊断失败原因

  • 增加分配的工作器资源

  • 使用新的资源限制测试 DAG

费用

本教程使用 Google Cloud 的以下收费组件:

完成本教程后,您可以删除所创建的资源以避免继续计费。如需了解详情,请参阅清理

准备工作

本部分介绍了在开始学习本教程之前需要执行的操作。

创建和配置项目

在本教程中,您需要一个 Google Cloud 项目。通过以下方式配置项目:

  1. 在 Google Cloud 控制台中,选择或创建项目

    前往项目选择器

  2. 确保您的项目已启用结算功能。 了解如何检查项目是否已启用结算功能

  3. 请确保您的 Google Cloud 项目用户拥有以下角色以创建必要的资源:

    • 环境和存储对象管理员 (roles/composer.environmentAndStorageObjectAdmin)
    • Compute Admin (roles/compute.admin)
    • Monitoring Editor (roles/monitoring.editor)

为您的项目启用 API

启用 Cloud Composer API。

启用 API

创建 Cloud Composer 环境

创建 Cloud Composer 2 环境

在创建环境的过程中,您要向 Composer Service Agent 帐号授予 Cloud Composer v2 API Service Agent Extension (roles/composer.ServiceAgentV2Ext) 角色。Cloud Composer 会使用此帐号在您的 Google Cloud 项目中执行操作。

查看工作器资源限制

检查您环境中的 Airflow 工作器资源限制:

  1. 在 Google Cloud 控制台中,前往环境页面。

    转到“环境”

  2. 在环境列表中,点击您的环境名称。环境详情页面会打开。

  3. 转到环境配置标签页。

  4. 转到 Resources(资源)> Workloads configuration(工作负载配置)>“Worker”。

  5. 检查值为 0.5 个 vCPU、1.875 GB 内存和 1 GB 存储空间。 这些是您将在本教程的后续步骤中处理的 Airflow 工作器资源限制。

示例:诊断内存不足问题

将以下示例 DAG上传到您在先前步骤中创建的环境。在本教程中,此 DAG 名为 create_list_with_many_strings

此 DAG 包含一项执行以下步骤的任务:

  1. 创建空列表 s
  2. 运行循环,将 More 字符串附加到列表中。
  3. 输出列表消耗的内存量,并在每 1 分钟迭代中等待 1 秒。
import time

import airflow
from airflow import DAG
from airflow.operators.python_operator import PythonOperator
import sys
from datetime import timedelta

default_args = {
    'start_date': airflow.utils.dates.days_ago(0),
    'retries': 0,
    'retry_delay': timedelta(minutes=10)
}

dag = DAG(
    'create_list_with_many_strings',
    default_args=default_args,
    schedule_interval=None)

def consume():
    s = []
    for i in range(120):
        for j in range(1000000):
            s.append("More")
        print(f"i={i}; size={sys.getsizeof(s) / (1000**3)}GB")
        time.sleep(1)

t1 = PythonOperator(
    task_id='task0',
    python_callable=consume,
    dag=dag,
    depends_on_past=False,
    retries=0
)

触发示例 DAG

触发示例 DAG create_list_with_many_strings

  1. 在 Google Cloud 控制台中,前往环境页面。

    转到“环境”

  2. Airflow Web 服务器列中,点击与您的环境对应的 Airflow 链接。

  3. 在 Airflow 网页界面中的 DAG 页面上,在您的 DAG 的链接列中,点击触发 Dag (Trigger Dag) 按钮。

  4. 点击触发器

  5. DAG 页面上,点击触发的任务并查看输出日志,确保您的 DAG 开始运行。

在任务运行时,输出日志将输出 DAG 使用的内存大小(以 GB 为单位)。

几分钟后,任务将失败,因为它超出了 Airflow 工作器内存限制 (1.875 GB)。

诊断失败的 DAG

如果在发生故障时您正在运行多个任务,请考虑仅运行一个任务并诊断该时间段内的资源压力,以确定哪些任务导致资源压力,以及您需要增加哪些资源。

查看 Airflow 任务日志

您会发现 create_list_with_many_strings DAG 中的任务具有 Failed 状态。

查看任务的日志。您将看到以下日志条目:

```none
{local_task_job.py:102} INFO - Task exited with return code
Negsignal.SIGKILL
```

`Netsignal.SIGKILL` might be an indication of your task using more memory
than the Airflow worker is allocated. The system sends
the `Negsignal.SIGKILL` signal to avoid further memory consumption.

查看工作负载

查看工作负载,确认您的任务的负载不会导致运行 Pod 的节点超出内存消耗限制:

  1. 在 Google Cloud 控制台中,前往环境页面。

    转到“环境”

  2. 在环境列表中,点击您的环境名称。环境详情页面会打开。

  3. 转到环境配置标签页。

  4. 资源 > GKE 集群 > 工作负载中,点击查看集群工作负载

  5. 检查某些工作负载 Pod 是否具有类似如下所示的状态:

    Error with exit code 137 and 1 more issue.
    ContainerStatusUnknown with exit code 137 and 1 more issue
    

    Exit code 137 表示容器或 Pod 尝试使用的内存超出允许的上限。系统会终止该进程以防止使用内存。

审核环境健康状况和资源消耗监控

查看环境健康状况和资源消耗情况的监控情况:

  1. 在 Google Cloud 控制台中,前往环境页面。

    转到“环境”

  2. 在环境列表中,点击您的环境名称。环境详情页面会打开。

  3. 转到监控标签页,然后选择概览

  4. 环境概览面板中,找到环境健康状况 (Airflow Monitoring DAG) 图表。它包含一个红色区域,该区域对应的是日志开始输出错误的时间。

  5. 选择工作器,然后找到工作器内存总用量图表。可以看到,内存用量行在任务运行时出现峰值。

在任务运行时,内存用量行出现峰值
图 1.工作器内存总用量图(点击可放大)

虽然图表上的内存用量行未达到上限,但在诊断失败原因时,您只需要考虑可分配的内存,而图表上的内存上限行表示可用的总内存(包括 GKE 预留的容量)。

在此示例中,工作器内存限制设置为 1.875 GB。GKE 会预留前 4 GiB 内存的 25%。GKE 还会预留一个额外的逐出阈值:每个节点上有 100 MiB 的内存用于 kubelet 逐出。

可分配内存的计算方式如下:

ALLOCATABLE = CAPACITY - RESERVED - EVICTION-THRESHOLD

如果内存限制为 1.875 GB,则实际可分配内存为:

1.75 GiB (1.875GB) - 0.44 (25% GiB reserved) - 0.1 = 1.21 GiB (~1.3 GB).

将此实际上限附加到内存用量图后,您会发现任务的内存用量峰值达到了实际内存上限,并且可以推断出任务因工作器内存不足而失败。

提高工作器内存限制

分配额外的工作器内存以使示例 DAG 成功运行:

  1. 在 Google Cloud 控制台中,前往环境页面。

    转到“环境”

  2. 在环境列表中,点击您的环境名称。环境详情页面会打开。

  3. 转到环境配置标签页。

  4. 找到资源 > 工作负载配置,然后点击修改

  5. 工作器部分的内存字段中,为 Airflow 工作器指定新的内存限制。在本教程中,请使用 3 GB。

  6. 保存更改并等待几分钟,以便 Airflow 工作器重启。

使用新的内存限制测试 DAG

再次触发 create_list_with_many_strings DAG 并等待其完成运行。

  1. 在 DAG 运行的输出日志中,您将看到 Marking task as SUCCESS,任务状态将指示 Success

  2. 查看 Monitoring 标签页中的环境概览部分,确保没有红色区域。

  3. 点击工作器部分,然后找到工作器内存总用量图表。您会看到内存限制行反映了内存限制的变化,内存使用量行远低于实际的可分配内存限制。

示例:诊断存储空间不足的问题

在此步骤中,您将上传两个用于创建大型文件的 DAG。第一个 DAG 会创建一个大型文件。第二个 DAG 会创建一个大型文件并模拟长时间运行的操作。

这两个 DAG 中的文件大小都超过了默认的 Airflow 工作器存储空间上限 1 GB,但第二个 DAG 需要执行额外的等待任务来人为地延长其持续时间。

您将在后续步骤中调查这两个 DAG 的行为差异。

上传用于创建大型文件的 DAG

将以下示例 DAG上传到您在先前步骤中创建的环境。在本教程中,此 DAG 名为 create_large_txt_file_print_logs

此 DAG 包含一项执行以下步骤的任务:

  1. 将 1.5 GB 的 localfile.txt 文件写入 Airflow 工作器存储空间。
  2. 使用 Python os 模块输出所创建文件的大小。
  3. 输出每 1 分钟 DAG 运行的时长。
import airflow
from airflow import DAG
from airflow.operators.python_operator import PythonOperator
import os
from datetime import timedelta
import time

default_args = {
    'start_date': airflow.utils.dates.days_ago(0),
    'retries': 0,
    'retry_delay': timedelta(minutes=10)
}

dag = DAG(
    'create_large_txt_file_print_logs',
    default_args=default_args,
    schedule_interval=None)

def consume():
    size = 1000**2  # bytes in 1 MB
    amount = 100

    def create_file():
        print(f"Start creating a huge file")
        with open("localfile.txt", "ab") as f:
            for j in range(15):
                f.write(os.urandom(amount) * size)
        print("localfile.txt size:", os.stat("localfile.txt").st_size / (1000**3), "GB")

    create_file()
    print("Success!")

t1 = PythonOperator(
    task_id='create_huge_file',
    python_callable=consume,
    dag=dag,
    depends_on_past=False,
    retries=0)

上传可在长时间运行的操作中创建大型文件的 DAG

如需模拟长时间运行的 DAG 并调查任务时长对结束状态的影响,请将第二个示例 DAG 上传到您的环境。在本教程中,此 DAG 名为 long_running_create_large_txt_file_print_logs

此 DAG 包含一项执行以下步骤的任务:

  1. 将 1.5 GB 的 localfile.txt 文件写入 Airflow 工作器存储空间。
  2. 使用 Python os 模块输出所创建文件的大小。
  3. 等待 1 小时 15 分钟来模拟对文件执行的操作(例如从文件读取)所需的时间。
  4. 输出每 1 分钟 DAG 运行的时长。
import airflow
from airflow import DAG
from airflow.operators.python_operator import PythonOperator
import os
from datetime import timedelta
import time

default_args = {
    'start_date': airflow.utils.dates.days_ago(0),
    'retries': 0,
    'retry_delay': timedelta(minutes=10)
}

dag = DAG(
    'long_running_create_large_txt_file_print_logs',
    default_args=default_args,
    schedule_interval=None)

def consume():
    size = 1000**2  # bytes in 1 MB
    amount = 100

    def create_file():
        print(f"Start creating a huge file")
        with open("localfile.txt", "ab") as f:
            for j in range(15):
                f.write(os.urandom(amount) * size)
        print("localfile.txt size:", os.stat("localfile.txt").st_size / (1000**3), "GB")

    create_file()
    for k in range(75):
        time.sleep(60)
        print(f"{k+1} minute")

    print("Success!")

t1 = PythonOperator(
    task_id='create_huge_file',
    python_callable=consume,
    dag=dag,
    depends_on_past=False,
    retries=0)

触发示例 DAG

触发第一个 DAG create_large_txt_file_print_logs

  1. 在 Google Cloud 控制台中,前往环境页面。

    转到“环境”

  2. Airflow Web 服务器列中,点击与您的环境对应的 Airflow 链接。

  3. 在 Airflow 网页界面中的 DAG 页面上,在您的 DAG 的链接列中,点击触发 Dag (Trigger Dag) 按钮。

  4. 点击触发器

  5. DAG 页面上,点击触发的任务并查看输出日志,确保您的 DAG 开始运行。

  6. 等待您使用 create_large_txt_file_print_logs DAG 创建的任务完成。这可能需要几分钟时间。

  7. DAG 页面上,点击 DAG 运行。您将看到任务处于 Success 状态,即使超出了存储限制。

查看任务 Airflow 日志:

  1. 在 Google Cloud 控制台中,前往环境页面。

    转到“环境”

    1. 在环境列表中,点击您的环境名称。环境详情页面会打开。

    2. 转到日志标签页,然后转到所有日志 > Airflow 日志 > 工作器 > 在日志浏览器中查看

    3. 按类型过滤日志:仅显示错误消息。

在日志中,您将看到类似于以下内容的消息:

Worker: warm shutdown (Main Process)

A worker pod was evicted at 2023-12-01T12:30:05Z with message: Pod ephemeral
local storage usage exceeds the total limit of containers 1023Mi.

这些日志表明,Pod 启动了“温关闭”过程,因为已使用的存储空间超出了限制,并在 1 小时后被逐出。但是,DAG 运行没有失败,因为它是在 Kubernetes 终止宽限期内完成的,本教程中对此进行了进一步说明。

为了说明终止宽限期的概念,请查看第二个示例 DAG long_running_create_large_txt_file_print_logs 的结果。

触发第二个 DAG long_running_create_large_txt_file_print_logs

  1. 在 Google Cloud 控制台中,前往环境页面。

    转到“环境”

  2. Airflow Web 服务器列中,点击与您的环境对应的 Airflow 链接。

  3. 在 Airflow 网页界面中的 DAG 页面上,在您的 DAG 的链接列中,点击触发 Dag (Trigger Dag) 按钮。

  4. 点击触发器

  5. DAG 页面上,点击触发的任务并查看输出日志,确保您的 DAG 开始运行。

  6. 等待 long_running_create_large_txt_file_print_logs DAG 运行失败。此过程大约需要 1 小时

查看 DAG 运行结果:

  1. DAG 页面上,点击 long_running_create_large_txt_file_print_logs DAG 运行。您会看到任务处于 Failed 状态,并且运行时长正好为 1 小时 5 分钟,少于任务的等待期(1 小时 15 分钟)。

  2. 查看任务的日志。DAG 在 Airflow 工作器的容器中创建 localfile.txt 文件后,日志会输出 DAG 开始等待的信息,并且任务日志每 1 分钟会输出一次运行时长。在此示例中,DAG 会输出 localfile.txt size: 日志,且 localfile.txt 文件的大小为 1.5 GB。

如果写入 Airflow 工作器容器的文件超出存储限制,DAG 运行应该会失败。但是,任务不会立即失败,而是一直运行,直到持续时长达到 1 小时 5 分钟。之所以发生这种情况,是因为 Kubernetes 不会立即终止任务,而是继续运行以留出 1 小时的恢复时间,称为“终止宽限期”。一旦节点耗尽资源,Kubernetes 不会立即终止 Pod 以妥善处理终止,从而最大限度地减少对最终用户的影响。

终止宽限期有助于用户在任务失败后恢复文件,但可能会导致在诊断 DAG 时出现混淆。如果超出 Airflow 工作器存储空间上限,任务的结束状态取决于 DAG 运行时长:

  • 如果 DAG 运行超出工作器存储空间限制,但在 1 小时内完成,则任务会在 Success 状态完成,因为它是在终止宽限期内完成的。但是,Kubernetes 会终止 Pod,写入的文件会立即从容器中删除。

  • 如果该 DAG 超过工作器存储空间限制且运行时间超过 1 小时,则该 DAG 将持续运行 1 小时,在 Kubernetes 移除 Pod 之前 Airflow 会将该任务标记为 Failed

诊断失败的 DAG

如果在发生故障时您正在运行多个任务,请考虑仅运行一个任务并诊断该时间段内的资源压力,以确定哪些任务导致资源压力,以及您需要增加哪些资源。

查看第二个 DAG (long_running_create_large_txt_file_print_logs) 的任务日志:

  1. 在 Google Cloud 控制台中,前往环境页面。

    转到“环境”

  2. 在环境列表中,点击您的环境名称。环境详情页面会打开。

  3. 转到日志标签页,然后转到所有日志 > Airflow 日志 > 工作器 > 在日志浏览器中查看

  4. 按类型过滤日志:仅显示错误消息。

在日志中,您将看到类似于以下内容的消息:

Container storage usage of worker reached 155.7% of the limit.

This likely means that the total size of local files generated by your DAGs is
close to the storage limit of worker.

You may need to decrease the storage usage or increase the worker storage limit
in your Cloud Composer environment configuration.

Pod storage usage of worker reached 140.2% of the limit.
A worker pod was evicted at 2023-12-01T12:30:05Z with message: Pod ephemeral
local storage usage exceeds the total limit of containers 1023Mi.

This eviction likely means that the total size of dags and plugins folders plus
local files generated by your DAGs exceeds the storage limit of worker.

Please decrease the storage usage or increase the worker storage limit in your
Cloud Composer environment configuration.

这些消息表示,随着任务的进行,如果 DAG 生成的文件大小超过工作器存储空间限制,并且终止宽限期已开始,则 Airflow 日志开始输出错误。在终止宽限期内,存储空间使用量未回到上限,这会导致终止宽限期结束后 Pod 被逐出。

查看环境健康状况和资源消耗情况的监控情况:

  1. 在 Google Cloud 控制台中,前往环境页面。

    转到“环境”

  2. 在环境列表中,点击您的环境名称。环境详情页面会打开。

  3. 转到监控标签页,然后选择概览

  4. 环境概览面板中,找到环境健康状况 (Airflow Monitoring DAG) 图表。它包含一个红色区域,该区域对应的是日志开始输出错误的时间。

  5. 选择工作器,然后找到工作器磁盘总用量图表。可以看到,在任务运行时,磁盘使用量行出现峰值,并超过磁盘限制行。

在您的任务运行时,磁盘使用量行出现峰值,并超过磁盘限额行
图 2.工作器磁盘总用量图(点击可放大)

提高工作器存储空间上限

分配额外的 Airflow 工作器存储空间以使示例 DAG 成功:

  1. 在 Google Cloud 控制台中,前往环境页面。

    转到“环境”

  2. 在环境列表中,点击您的环境名称。环境详情页面会打开。

  3. 转到环境配置标签页。

  4. 找到资源 > 工作负载配置,然后点击修改

  5. 工作器部分的存储字段中,为 Airflow 工作器指定新的存储限制。在本教程中,将其设置为 2 GB。

  6. 保存更改并等待几分钟,以便 Airflow 工作器重启。

使用新的存储空间限额测试您的 DAG

再次触发 long_running_create_large_txt_file_print_logs DAG 并等待 1 小时 15 分钟,直到它完成运行。

  1. 在 DAG 运行的输出日志中,您将看到 Marking task as SUCCESS,任务的状态将指示 Success,持续时间为 1 小时 15 分钟,等于 DAG 代码中设置的等待时间。

  2. 查看 Monitoring 标签页中的环境概览部分,确保没有红色区域。

  3. 点击工作器部分,然后找到工作器磁盘总用量图表。您将看到磁盘限制行反映了存储限制的变化,并且磁盘使用率行在允许范围内。

摘要

在本教程中,您通过调试因工作器内存和存储空间不足而失败的两个示例 DAG 诊断了 DAG 故障的原因,并确定了造成压力的资源类型。然后,您在为工作器分配了更多内存和存储空间后,成功运行了这些 DAG。但是,建议您优化 DAG(工作流)以从源头减少工作器资源消耗,因为无法将资源增加到特定阈值以上。

清理

为避免因本教程中使用的资源导致您的 Google Cloud 帐号产生费用,请删除包含这些资源的项目,或者保留项目但删除各个资源。

删除项目

  1. 在 Google Cloud 控制台中,进入管理资源页面。

    转到“管理资源”

  2. 在项目列表中,选择要删除的项目,然后点击删除
  3. 在对话框中输入项目 ID,然后点击关闭以删除项目。

删除各个资源

如果您打算探索多个教程和快速入门,重复使用项目可以帮助您避免超出项目配额上限。

删除 Cloud Composer 环境。在此过程中,您还需要删除环境的存储桶。

后续步骤