已知問題

本頁說明您在使用 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 替換為與您要工作使用的預留資源相符的 VM 資源。

如需更多操作說明，請參閱建立及執行可耗用預留 VM 的工作和為工作定義自訂標籤。

找出問題

這個問題不會顯示任何特定錯誤訊息。不過，這個問題可能會在下列情況中發生：

  • 如果專案保留了所有配額資源，指定這些資源的工作就會無法執行。

    舉例來說，假設您的專案包含下列項目：

    • H100 GPU 的配額上限為 16。
    • 未使用的單一專案保留項目，適用於 2 個 a3-highgpu-8g VM，總共保留 16 個 H100 GPU。

    在這種情況下，這個問題會導致專案無法排定及執行任何已正確設定為使用預留 H100 GPU 的工作。

  • 如果專案保留部分配額資源，可能會導致指定這些資源的工作無法執行或延遲執行。

    舉例來說，假設您的專案包含下列項目：

    • H100 GPU 的配額上限為 16。
    • 未使用的單一專案保留項目，適用於 1 個 a3-highgpu-8g VM，總共保留 8 個 H100 GPU。
    • 設定為不使用任何預留項目的 a3-highgpu-8g VM，偶爾會遭到刪除並重新建立。(如果存在，這個 VM 會使用 8 個未預留的 H100 GPU)。

    在此情境中，如果 a3-highgpu-8g VM 不存在，這個問題只會允許專案排定及開始執行任何已正確設定的工作，以使用任何預留的 H100 GPU。

指定使用核心版本過舊的 Compute Engine (或自訂) VM OS 映像檔時，工作可能會失敗

如果工作指定的 Compute Engine VM OS 映像檔不是最新核心版本，工作可能會失敗。以 Compute Engine VM OS 映像檔為基礎的任何自訂映像檔，也會受到這個問題影響。造成這個問題的 Compute Engine 公開映像檔不容易識別，且隨時可能變更。

這個問題不會顯示特定錯誤訊息。如果工作意外失敗，且指定 Compute Engine VM OS 映像檔或類似的自訂映像檔，請考慮這個問題。

如要避免或解決這個問題，請採取下列做法：

  1. 請盡可能使用 Batch 圖片或以 Batch 圖片為基礎的自訂圖片，這類圖片不受此問題影響。
  2. 如果無法使用 Batch 映像檔，請嘗試使用偏好的最新版 Compute Engine 映像檔。一般來說，新版 Compute Engine 映像檔比舊版更有可能搭載最新版核心。
  3. 如果特定映像檔的最新版本無法運作，您可能需要嘗試使用其他 OS 或建立自訂映像檔。舉例來說，如果最新版 Debian 11 無法運作，您可以嘗試從執行 Debian 11 的 Compute Engine VM 建立自訂映像檔，並將該 VM 更新為使用最新核心版本。

這個問題是因 VM OS 映像檔中的核心版本過舊，導致 VM 重新啟動。如果作業指定的 VM OS 映像檔不是來自 Batch，也不是以 Batch 映像檔為基礎，Batch 會在作業的 VM 啟動後，在這些 VM 上安裝必要套件。不同工作所需的套件可能不同，且會隨時間變更，因此 VM OS 映像檔可能需要使用最新核心版本。更新核心版本時，VM 必須重新啟動，導致套件安裝作業和工作失敗，就會發生這個問題。

如要進一步瞭解 VM OS 映像檔，請參閱「作業 VM 的 OS 環境總覽」。

如果工作使用 GPU，且 VM OS 映像檔的核心版本過舊，只有在自動安裝驅動程式時可能會失敗

這個問題與「指定使用核心版本過舊的 Compute Engine (或自訂) VM OS 映像檔時，工作可能會失敗」密切相關。具體來說，如果工作指定使用沒有最新核心的 Compute Engine (或自訂) VM OS 映像檔，且使用 GPU，只有在您嘗試自動安裝 GPU 驅動程式時，工作才可能會失敗。對於這類作業，您或許只要手動安裝 GPU 驅動程式，就能解決失敗問題。

如要進一步瞭解 GPU，請參閱建立及執行使用 GPU 的工作。