已知问题

本页面介绍了您在使用 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 可能会错误地延迟或阻止作业运行。具体而言，即使项目中的Compute Engine 资源配额正被未使用的预留占用，Batch 仍要求项目拥有足够的此类配额。

解决此问题

如需针对作业解决此问题，请向作业级 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 个未使用的单项目预留，用于 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 11 无法正常运行，您可以尝试从运行 Debian 11 且已更新为使用最新内核版本的 Compute Engine 虚拟机创建自定义映像。

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

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

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

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

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