Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

Masalah umum

Halaman ini menjelaskan masalah umum yang mungkin Anda alami saat menggunakan Batch.

Jika Anda memerlukan bantuan lebih lanjut dalam menggunakan Batch, lihat dokumentasi Pemecahan masalah atau Mendapatkan dukungan.

Pub/Sub mungkin tidak mengirimkan notifikasi untuk status perantara selama perubahan cepat

Pub/Sub mungkin tidak mengirim notifikasi untuk semua status perantara saat tugas atau pekerjaan berubah dengan sangat cepat. Misalnya, anggaplah tugas berubah status dengan cepat dari ASSIGNED, lalu RUNNING, dan kemudian FAILED. Dalam skenario tersebut, Anda mungkin tidak mendapatkan notifikasi bahwa tugas telah mencapai status RUNNING.

Untuk mengatasi masalah ini, sebaiknya, saat Anda ingin melihat histori status lengkap tugas atau pekerjaan, lihat peristiwa status, bukan notifikasi Pub/Sub.

Untuk mengetahui informasi selengkapnya tentang notifikasi Pub/Sub, lihat Memantau status tugas menggunakan notifikasi Pub/Sub dan BigQuery.

Log waktu tunggu tidak menunjukkan apakah waktu tunggu tugas atau runnable telah terlampaui

Jika tugas gagal karena melebihi waktu tunggu, log yang terkait dengan tugas tidak menunjukkan apakah kegagalan disebabkan oleh waktu tunggu tugas yang relevan atau waktu tunggu runnable yang relevan.

Untuk mengatasi masalah ini, tetapkan nilai waktu tunggu yang berbeda untuk tugas dan runnable. Kemudian, Anda dapat mengidentifikasi apakah kegagalan disebabkan oleh melebihi waktu tunggu tugas atau runnable yang relevan menggunakan prosedur berikut:

Mengidentifikasi tugas, runnable, dan waktu kegagalan karena waktu tunggu terlampaui.
1. Lihat log untuk tugas.
2. Temukan log yang menyebutkan kode keluar exceeded-timeout, 50005. Log ini memiliki textPayload yang mirip dengan pesan berikut:
```
Task task/JOB_UID-group0-TASK_INDEX/0/0 runnable RUNNABLE_INDEX...exitCode 50005
```
  Dari log tersebut, catat TASK_INDEX sebagai tugas yang gagal, RUNNABLE_INDEX sebagai runnable yang gagal, dan nilai timestamp log sebagai waktu kegagalan karena waktu tunggu terlampaui.
Identifikasi waktu mulai tugas yang gagal.
1. Melihat peristiwa status tugas yang gagal.
2. Temukan peristiwa status yang menyebutkan pesan berikut:
```
Task state is updated from ASSIGNED to RUNNING
```
  Dari peristiwa status tersebut, catat kolom eventTime sebagai waktu mulai tugas yang gagal.
Hitung total waktu proses tugas yang gagal, \({failedTaskRunTime}\), menggunakan formula berikut:

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

Ganti nilai berikut:
- \({failureTime}\): waktu kegagalan karena waktu tunggu habis.
- \({failedTaskStartTime}\): waktu mulai tugas yang gagal.
Identifikasi waktu tunggu yang terlampaui:
- Jika \({failedTaskRunTime}\) cocok dengan waktu tunggu yang Anda konfigurasi untuk tugas yang gagal, maka waktu tunggu tugas yang gagal tersebut telah terlampaui dan menyebabkan kegagalan.
- Jika tidak, waktu tunggu yang Anda konfigurasi untuk runnable yang gagal telah terlampaui dan menyebabkan kegagalan.

Tugas yang menggunakan reservasi mungkin tertunda atau dicegah

Saat Anda mencoba membuat dan menjalankan tugas yang menggunakan reservasi Compute Engine, Batch mungkin menunda atau mencegah tugas berjalan dengan tidak benar. Secara khusus, Batch mewajibkan project untuk memiliki kuota resource Compute Engine yang memadai bahkan saat kuota resource tersebut digunakan oleh pemesanan yang tidak digunakan.

Mengatasi masalah

Untuk mengatasi masalah ini pada tugas, tambahkan label dengan nama goog-batch-skip-quota-check dan nilai true ke kolom labels tingkat tugas. Label ini menyebabkan Batch melewati verifikasi kuota resource project Anda sebelum mencoba membuat tugas.

Misalnya, untuk mencegah atau menyelesaikan masalah ini pada tugas skrip dasar yang dapat menggunakan reservasi, buat dan jalankan tugas dengan konfigurasi JSON berikut:

{
  "taskGroups": [
    {
      "taskSpec": {
        "runnables": [