已知问题

本页面介绍在使用 Batch 时可能遇到的已知问题。

如果您在使用 Batch 时需要进一步帮助,请参阅 问题排查文档或 获取支持

Pub/Sub 可能不会针对快速更改期间的中间状态发送通知

当作业或任务快速更改时,Pub/Sub 可能不会针对所有中间状态发送通知。例如,假设任务的状态快速从 ASSIGNED 更改为 RUNNING,然后更改为 FAILED。在这种情况下,您可能不会收到任务已达到 RUNNING 状态的通知。

为缓解此问题,我们建议您在想要查看作业或任务的完整 状态历史记录时, 查看状态事件 而不是 Pub/Sub 通知。

如需详细了解 Pub/Sub 通知,请参阅 使用 Pub/Sub 通知和 BigQuery 监控作业状态

超时日志不会指明任务或可运行对象的超时时间是否已超出

当作业因超出超时时间而失败时, 与该作业关联的日志不会指明失败 是由相关任务的超时时间还是相关可运行对象的超时时间导致的。

如需解决此问题,请为任务和可运行对象设置不同的超时值。然后,您可以按照以下步骤确定失败是由超出相关任务或可运行对象的超时时间导致的:

  1. 确定超出超时时间失败的任务、可运行对象和时间。

    1. 查看作业的日志

    2. 找到提及超出超时时间退出代码 50005 的日志。 此日志具有类似于以下消息的 textPayload

      Task task/JOB_UID-group0-TASK_INDEX/0/0 runnable RUNNABLE_INDEX...exitCode 50005
      

      从该日志中,将 TASK_INDEX 记录为失败的任务,将 RUNNABLE_INDEX 记录为失败的可运行对象,并将日志的 timestamp 值记录为超出超时时间失败的时间。

  2. 确定失败任务的开始时间。

    1. 查看失败任务的状态事件

    2. 找到提及以下消息的状态事件:

      Task state is updated from ASSIGNED to RUNNING
      

      从该状态事件中,将 eventTime 字段记录为失败任务的开始时间。

  3. 使用以下公式计算失败任务的总运行时间: \({failedTaskRunTime}\),通过使用

    \[{failedTaskRunTime}={failureTime}-{failedTaskStartTime}\]

    替换以下值:

    • \({failureTime}\):超出超时时间失败的时间。
    • \({failedTaskStartTime}\):失败任务的开始时间。
  4. 确定超出的超时时间:

    • 如果 \({failedTaskRunTime}\) 与您为 失败任务配置的超时时间匹配,则表示该失败任务的超时时间已超出并导致 失败。

    • 否则,表示您为失败的可运行对象配置的超时时间已超出并导致失败。

使用预留的作业可能会延迟或无法运行

当您尝试 创建和运行使用 Compute Engine 预留的作业时, Batch 可能会错误地延迟或阻止作业 运行。具体而言,即使未使用的预留正在使用这些资源配额,Batch 仍要求项目具有足够的 Compute Engine 资源配额

解决此问题

如需解决作业的此问题,请向 作业级labels字段添加一个标签,其 名称goog-batch-skip-quota-check和值true。 此标签会导致 Batch 在尝试创建作业之前跳过验证项目的资源配额。

例如,如需防止或解决基本脚本作业(可以使用预留)的此问题,请创建并运行具有以下 JSON 配置的作业:

{
  "taskGroups": [
    {
      "taskSpec": {
        "runnables": [
          {
            "script": {
              "text": "echo Hello world from task ${BATCH_TASK_INDEX}"
            }
          }
        ]
      },
      "taskCount": 3
    }
  ],
  "allocationPolicy": {
    "instances": [
      {
        VM_RESOURCES
      }
    ],
  },
  "labels": {
    "goog-batch-skip-quota-check": "true"
  },
  "logsPolicy": {
    "destination": "CLOUD_LOGGING"
  }
}

VM_RESOURCES 替换为与您希望作业使用的预留匹配的虚拟机资源。

如需了解更多说明,请参阅 创建和运行可以使用预留虚拟机的作业为作业定义自定义标签

找出问题

此问题不会通过任何特定错误消息指明。相反,此问题可能会在以下情况下发生:

  • 如果您的项目预留了其配额中的所有资源,则此问题会阻止指定这些资源的任何作业。

    例如,假设您的项目具有以下内容:

    • H100 GPU 的最大配额为 16。
    • 2 个 a3-highgpu-8g 虚拟机的未使用的单项目预留,总共预留了 16 个 H100 GPU。

    在这种情况下,此问题会阻止您的项目调度和运行任何正确配置为使用任何预留的 H100 GPU 的作业。

  • 如果您的项目预留了其配额中的部分资源,则此问题可能会阻止或延迟指定这些资源的作业。

    例如,假设您的项目具有以下内容:

    • H100 GPU 的最大配额为 16。
    • 1 个 a3-highgpu-8g 虚拟机的未使用的单项目预留,总共预留了 8 个 H100 GPU。
    • 一个 a3-highgpu-8g 虚拟机,该虚拟机配置为 不使用任何预留 并且偶尔会被删除然后重新创建。 (此虚拟机存在时会使用 8 个未预留的 H100 GPU。)

    在这种情况下,此问题仅允许您的项目在 a3-highgpu-8g 虚拟机不存在时调度并开始运行任何正确配置为使用任何预留的 H100 GPU 的作业。

指定具有过时内核的 Compute Engine(或自定义)虚拟机操作系统映像时,作业可能会失败

如果作业指定的 Compute Engine 虚拟机操作系统映像没有最新的内核版本,则该作业可能会失败。 此问题还会影响基于 Compute Engine 虚拟机操作系统映像的任何自定义映像。 导致此问题的 Compute Engine 公共映像不易识别,并且随时可能会发生变化。

此问题不会通过特定错误消息指明。相反,如果您有意外失败的作业,并且该作业指定了 Compute Engine 虚拟机操作系统映像或类似的自定义映像,请考虑此问题。

如需防止或解决此问题,您可以执行以下操作:

  1. 尽可能使用 Batch 映像或基于 Batch 映像的自定义映像,这些映像不受此问题的影响。
  2. 如果您无法使用 Batch 映像,请尝试使用首选 Compute Engine 映像的最新版本。一般来说,较新版本的 Compute Engine 映像比旧版本更有可能具有最新的内核版本。
  3. 如果特定映像的最新版本不起作用,您可能需要尝试其他操作系统或创建自定义映像。 例如,如果 Debian 12 的最新版本不起作用,您可以尝试从运行 Debian 12 且已更新为使用最新内核版本的 Compute Engine 虚拟机创建自定义映像。

此问题是由虚拟机操作系统映像中的过时内核版本导致的,该版本会导致虚拟机重启。当作业指定任何不是来自 Batch 或基于 Batch 映像的虚拟机操作系统映像时,Batch 会在作业的虚拟机启动后在其上安装所需的软件包。不同作业所需软件包可能不同,并且会随时间而变化,它们可能要求您的虚拟机操作系统映像具有最新的内核版本。当更新内核版本需要虚拟机重启时,会出现此问题,这会导致软件包安装和作业失败。

如需详细了解虚拟机操作系统映像,请参阅 作业虚拟机的操作系统环境概览

仅在自动安装驱动程序时,使用 GPU 和具有过时内核的虚拟机操作系统映像的作业可能会失败

此问题与 指定具有过时内核的 Compute Engine(或自定义)虚拟机操作系统映像时,作业可能会失败密切相关。 具体而言,如果作业同时指定了没有最新内核的 Compute Engine(或自定义)虚拟机操作系统映像并使用 GPU,则仅当您尝试自动安装 GPU 驱动程序时,作业可能会失败。对于这些作业,您可能只需手动安装 GPU 驱动程序即可解决失败问题。

如需详细了解 GPU,请参阅 创建和运行使用 GPU 的作业