Memecahkan masalah tugas yang lambat atau macet

Halaman ini menjelaskan cara memecahkan masalah penyebab umum lambatnya atau macetnya tugas batch dan streaming Dataflow.

Streaming

Jika Anda melihat gejala berikut, tugas streaming Dataflow Anda mungkin berjalan lambat atau macet:

Gunakan informasi di bagian berikut untuk mengidentifikasi dan mendiagnosis masalah.

Mengidentifikasi akar masalah

  1. Periksa metrik keaktualan data dan byte backlog.

    • Jika kedua metrik meningkat secara monoton, berarti pipeline macet dan tidak berjalan.
    • Jika keaktualan data meningkat, tetapi byte backlog tetap normal, artinya satu atau beberapa item kerja macet di pipeline.

    Cari tahap saat metrik ini meningkat, untuk mengidentifikasi tahap yang bermasalah dan operasi yang dilakukan pada tahap tersebut.

  2. Periksa Diagram pemrosesan paralel untuk melihat apakah ada tahap yang macet karena paralelisme yang berlebihan atau tidak memadai. Lihat Memecahkan masalah paralelisme.

  3. Periksa log tugas untuk mengetahui masalah seperti batas kuota, masalah kehabisan stok, atau kehabisan alamat IP.

  4. Periksa peringatan dan error di log pekerja.

    • Jika log pekerja berisi error, lihat pelacakan tumpukan. Selidiki apakah error disebabkan oleh bug dalam kode Anda.
    • Cari error Dataflow. Lihat Memecahkan masalah error Dataflow.
    • Cari error yang menunjukkan bahwa tugas melampaui batas, seperti ukuran pesan Pub/Sub maksimum.
    • Cari error kehabisan memori, yang dapat menyebabkan pipeline macet. Jika Anda melihat error kurang memori, ikuti langkah-langkah di Memecahkan masalah error kurang memori Dataflow.
    • Untuk mengidentifikasi langkah yang lambat atau macet, periksa log pekerja untuk pesan Operation ongoing. Lihat pelacakan tumpukan untuk melihat tempat langkah menghabiskan waktu. Untuk mengetahui informasi selengkapnya, lihat Pemrosesan macet atau operasi sedang berlangsung.

  5. Jika item kerja macet di pekerja tertentu, mulai ulang VM pekerja tersebut.

  6. Jika Anda tidak menggunakan Streaming Engine, periksa log pengacak untuk mengetahui peringatan dan error. Jika Anda melihat error waktu tunggu RPC di port 12345 atau 12346, tugas Anda mungkin tidak memiliki aturan firewall. Lihat Aturan firewall untuk Dataflow.

  7. Periksa tombol pintas.

  8. Jika Runner v2 diaktifkan, periksa log harness untuk menemukan error. Untuk mengetahui informasi selengkapnya, lihat Memecahkan masalah Runner v2.

Menyelidiki kegagalan berulang

Dalam tugas streaming, beberapa kegagalan dicoba ulang tanpa batas. Upaya percobaan ulang ini mencegah progres pipeline. Untuk mengidentifikasi kegagalan berulang, periksa log pekerja untuk menemukan pengecualian.

Mengidentifikasi pekerja yang tidak responsif

Jika pekerja yang memproses tugas streaming tidak dalam kondisi baik, tugas mungkin berjalan lambat atau tampak macet. Untuk mengidentifikasi pekerja yang tidak responsif:

Mengidentifikasi pengikut yang tertinggal

Item lambat adalah item kerja yang lambat dibandingkan dengan item kerja lainnya dalam tahap. Untuk mengetahui informasi tentang cara mengidentifikasi dan memperbaiki tugas yang tertinggal, lihat Memecahkan masalah tugas yang tertinggal dalam tugas streaming.

Memecahkan masalah paralelisme

Untuk skalabilitas dan efisiensi, Dataflow menjalankan tahap pipeline Anda secara paralel di beberapa pekerja. Unit pemrosesan paralel terkecil di Dataflow adalah kunci. Pesan masuk untuk setiap tahap gabungan dikaitkan dengan kunci. Kunci ditentukan dengan salah satu cara berikut:

  • Kunci didefinisikan secara implisit oleh properti sumber, seperti partisi Kafka.
  • Kunci ditentukan secara eksplisit oleh logika agregasi dalam pipeline, seperti GroupByKey.

Di Dataflow, thread pekerja bertanggung jawab untuk menangani pemrosesan paket tugas (pesan) untuk suatu kunci. Jumlah thread yang tersedia untuk memproses kunci tugas sama dengan num_of_workers * threads_per_worker. Jumlah thread per pekerja ditentukan berdasarkan SDK (Java, Python, atau Go) dan jenis tugas (batch atau streaming).

Jika pipeline tidak memiliki cukup kunci untuk tahap tertentu, pipeline akan membatasi pemrosesan paralel. Tahap tersebut dapat menjadi hambatan.

Jika pipeline menggunakan sejumlah besar kunci untuk tahap tertentu, hal ini dapat membatasi throughput tahap tersebut dan mengakumulasi backlog di tahap upstream, karena ada beberapa overhead per kunci. Overhead dapat mencakup komunikasi backend ke pekerja, RPC eksternal ke sink seperti BigQuery, dan pemrosesan lainnya. Misalnya, jika pemrosesan kunci dengan satu pesan memerlukan waktu 100 md, pemrosesan 1.000 pesan dalam paket kunci tersebut juga memerlukan waktu sekitar 100 md.

Mengidentifikasi tahap dengan paralelisme rendah

Untuk mengidentifikasi apakah kelambatan pipeline disebabkan oleh paralelisme rendah, lihat metrik penggunaan CPU. Jika CPU rendah tetapi didistribusikan secara merata di seluruh pekerja, tugas Anda mungkin memiliki paralelisme yang tidak memadai. Jika tugas Anda menggunakan Streaming Engine, untuk melihat apakah tahap memiliki paralelisme rendah, di tab Metrik Tugas, lihat metrik paralelisme. Untuk mengurangi masalah ini:

  • Di konsol Google Cloud , pada halaman Info tugas, gunakan tab Penskalaan otomatis untuk melihat apakah tugas mengalami masalah saat melakukan penskalaan. Jika penskalaan otomatis menjadi masalah, lihat Memecahkan masalah penskalaan otomatis Dataflow.
  • Gunakan grafik tugas untuk memeriksa langkah-langkah dalam tahap. Jika tahap membaca dari sumber atau menulis ke tujuan, tinjau dokumentasi untuk layanan sumber atau tujuan. Gunakan dokumentasi untuk menentukan apakah layanan tersebut dikonfigurasi untuk skalabilitas yang memadai.

Mengidentifikasi tahap dengan paralelisme tinggi

Kombinasi latensi sistem yang rendah, keaktualan data yang meningkat, serta backlog yang meningkat dan CPU pekerja yang kurang dimanfaatkan menunjukkan bahwa pipeline mengalami pembatasan karena jumlah kunci yang besar. Periksa diagram pemrosesan paralel untuk mengidentifikasi tahap dengan sejumlah besar kunci.

Transformasi seperti Reshuffle dapat menghasilkan jutaan kunci jika Anda tidak menentukan withNumBuckets secara eksplisit. Sejumlah besar kunci dapat menyebabkan pembuatan banyak paket kerja yang lebih kecil, yang masing-masing memerlukan thread pekerja khusus untuk diproses. Karena thread pekerja yang tersedia terbatas, hal ini dapat menyebabkan backlog yang signifikan dalam pemrosesan kunci, sehingga menyebabkan penundaan saat kunci menunggu resource. Akibatnya, thread pekerja tidak digunakan secara efisien.

Sebaiknya batasi jumlah kunci dengan menetapkan opsi withNumBuckets dalam transformasi Reshuffle. Nilai tidak boleh melebihi jumlah total thread di semua pekerja. Menargetkan kunci (threads_per_worker * max_workers) dalam pipeline mungkin tidak optimal. Terkadang, jumlah kunci yang lebih sedikit dan paket yang lebih besar dapat dilakukan, dan diproses secara lebih efisien oleh Dataflow karena menggunakan lebih sedikit pekerja. Jumlah kunci yang lebih kecil akan membuat paket tugas yang lebih besar, yang secara efisien menggunakan thread pekerja dan meningkatkan throughput tahap.

Jika ada beberapa langkah Reshuffle dalam pipeline, bagi jumlah total thread dengan jumlah langkah Reshuffle untuk menghitung withNumBuckets.

Memeriksa tombol cepat

Jika tugas didistribusikan secara tidak merata di seluruh pekerja dan pemanfaatan pekerja sangat tidak merata, pipeline Anda mungkin memiliki kunci panas. Tombol panas adalah tombol yang memiliki lebih banyak elemen untuk diproses dibandingkan dengan tombol lainnya.

Periksa tombol pintas menggunakan filter log berikut:

  resource.type="dataflow_step"
  resource.labels.job_id=JOB_ID
  jsonPayload.line:"hot_key_logger"

Ganti JOB_ID dengan ID tugas Anda.

Untuk mengatasi masalah ini, lakukan satu atau beberapa langkah berikut:

  • Masukkan ulang data Anda. Untuk menghasilkan key-value pair baru, terapkan transformasi ParDo. Untuk mengetahui informasi selengkapnya, lihat halaman transformasi ParDo Java atau halaman transformasi ParDo Python dalam dokumentasi Apache Beam.
  • Gunakan .withFanout dalam transformasi gabungan Anda. Untuk mengetahui informasi selengkapnya, lihat kelas Combine.PerKey di Java SDK atau operasi with_hot_key_fanout di Python SDK.
  • Jika Anda memiliki pipeline Java yang memproses PCollections tanpa batas bervolume tinggi, sebaiknya lakukan hal berikut:
    • Gunakan Combine.Globally.withFanout, bukan Combine.Globally.
    • Gunakan Combine.PerKey.withHotKeyFanout, bukan Count.PerKey.

Memeriksa kuota yang tidak mencukupi

Pastikan Anda memiliki kuota yang cukup untuk sumber dan tujuan Anda. Misalnya, jika pipeline Anda membaca input dari Pub/Sub atau BigQuery, Google Cloud project Anda mungkin memiliki kuota yang tidak mencukupi. Untuk mengetahui informasi selengkapnya tentang batas kuota untuk layanan ini, lihat kuota Pub/Sub atau kuota BigQuery.

Jika tugas Anda menghasilkan banyak error 429 (Rate Limit Exceeded), tugas tersebut mungkin memiliki kuota yang tidak mencukupi. Untuk memeriksa error, coba langkah-langkah berikut:

  1. Buka Google Cloud console.
  2. Di panel navigasi, klik APIs & services.
  3. Di menu, klik Koleksi.
  4. Gunakan kotak penelusuran untuk menelusuri Pub/Sub.
  5. Klik Cloud Pub/Sub API.
  6. Klik Kelola.
  7. Pada diagram Traffic by response code, cari kode error klien (4xx).

Anda juga dapat menggunakan Metrics Explorer untuk memeriksa penggunaan kuota. Jika pipeline Anda menggunakan sumber atau tujuan BigQuery, untuk memecahkan masalah kuota, gunakan metrik BigQuery Storage API. Misalnya, untuk membuat diagram yang menampilkan jumlah koneksi serentak BigQuery, ikuti langkah-langkah berikut:

  1. Di konsol Google Cloud , pilih Monitoring:

    Buka Monitoring

  2. Di panel navigasi, pilih Metrics Explorer.

  3. Di panel Pilih metrik, untuk Metrik, filter ke Project BigQuery > Tulis > jumlah koneksi serentak.

Untuk mengetahui petunjuk tentang cara melihat metrik Pub/Sub, lihat Memantau penggunaan kuota di "Memantau Pub/Sub di Cloud Monitoring". Untuk mengetahui petunjuk tentang cara melihat metrik BigQuery, lihat Melihat penggunaan dan batas kuota di "Membuat dasbor, diagram, dan pemberitahuan".

Batch

Jika tugas batch Anda lambat atau macet, gunakan tab Detail eksekusi untuk menemukan informasi selengkapnya tentang tugas dan mengidentifikasi tahap atau pekerja yang menyebabkan hambatan.

Mengidentifikasi akar masalah

  1. Periksa apakah tugas mengalami masalah selama startup pekerja. Untuk mengetahui informasi selengkapnya, lihat Error saat menyinkronkan pod.

    Untuk memverifikasi bahwa tugas telah mulai memproses data, lihat entri log job-message berikut:

    All workers have finished the startup processes and began to receive work requests

  2. Untuk membandingkan performa tugas di antara tugas yang berbeda, pastikan volume data input, konfigurasi pekerja, perilaku penskalaan otomatis, dan setelan Pengacakan Dataflow sama.

  3. Periksa log job-message untuk mengetahui masalah seperti batas kuota, masalah kehabisan stok, atau kehabisan alamat IP.

  4. Di tab Detail eksekusi, bandingkan progres tahap untuk mengidentifikasi tahap yang memerlukan waktu lebih lama.

  5. Cari tugas yang tertinggal. Untuk mengetahui informasi selengkapnya, lihat Memecahkan masalah tugas batch yang tertunda.

  6. Periksa metrik throughput, CPU, dan pemakaian memori.

  7. Periksa log pekerja untuk melihat peringatan dan error.

  8. Periksa tombol pintas.

  9. Jika Anda tidak menggunakan Pengacakan Dataflow, periksa log pengacak untuk mengetahui peringatan dan error selama operasi pengacakan. Jika Anda melihat error waktu tunggu RPC di port 12345 atau 12346, tugas Anda mungkin tidak memiliki aturan firewall. Lihat Aturan firewall untuk Dataflow.

  10. Jika Runner v2 diaktifkan, periksa log harness untuk menemukan error. Untuk mengetahui informasi selengkapnya, lihat Memecahkan masalah Runner v2.

Mengidentifikasi pengikut yang tertinggal

Item lambat adalah item kerja yang lambat dibandingkan dengan item kerja lainnya dalam tahap. Untuk mengetahui informasi tentang mengidentifikasi dan memperbaiki tugas yang tertinggal, lihat Memecahkan masalah tugas yang tertinggal dalam tugas batch.

Mengidentifikasi tahap yang lambat atau macet

Untuk mengidentifikasi tahap yang lambat atau macet, gunakan tampilan Progres tahap. Batang yang lebih panjang menunjukkan bahwa tahap tersebut membutuhkan lebih banyak waktu. Gunakan tampilan ini untuk mengidentifikasi tahap terlama dalam pipeline Anda.

Setelah menemukan tahap hambatan, Anda dapat melakukan langkah-langkah berikut:

  • Identifikasi pekerja yang tertinggal dalam tahap tersebut.
  • Jika tidak ada pekerja yang tertinggal, identifikasi langkah paling lambat menggunakan panel Info tahap. Gunakan informasi ini untuk mengidentifikasi kandidat pengoptimalan kode pengguna.
  • Untuk menemukan hambatan paralelisme, gunakan Metrik pemantauan Dataflow.

Mengidentifikasi pekerja yang tertinggal

Untuk mengidentifikasi pekerja yang tertinggal di tahap tertentu, gunakan tampilan Progres pekerja. Tampilan ini menunjukkan apakah semua pekerja memproses pekerjaan hingga akhir tahap, atau apakah satu pekerja mengalami masalah pada tugas yang tertunda. Jika Anda menemukan pekerja yang lambat, lakukan langkah-langkah berikut:

Alat untuk proses debug

Jika pipeline Anda lambat atau macet, alat berikut dapat membantu Anda mendiagnosis masalah tersebut.

  • Untuk mengorelasikan insiden dan mengidentifikasi hambatan, gunakan Cloud Monitoring untuk Dataflow.
  • Untuk memantau performa pipeline, gunakan Cloud Profiler.
  • Beberapa transformasi lebih cocok untuk pipeline bervolume tinggi daripada yang lain. Pesan log dapat mengidentifikasi transformasi pengguna yang macet di pipeline batch atau streaming.
  • Untuk mempelajari lebih lanjut tugas yang macet, gunakan Metrik tugas Dataflow. Daftar berikut mencakup metrik yang berguna:
    • Metrik Backlog bytes (backlog_bytes) mengukur jumlah input yang belum diproses dalam byte menurut tahap. Gunakan metrik ini untuk menemukan langkah gabungan yang tidak memiliki throughput. Demikian pula, metrik elemen backlog (backlog_elements) mengukur jumlah elemen input yang belum diproses untuk suatu tahap.
    • Metrik Kunci paralelisme pemrosesan (processing_parallelism_keys) mengukur jumlah kunci pemrosesan paralel untuk tahap tertentu dalam pipeline selama lima menit terakhir. Gunakan metrik ini untuk menyelidiki dengan cara berikut:
      • Persempit masalah ke tahap tertentu dan konfirmasi peringatan tombol pintas, seperti A hot key ... was detected.
      • Menemukan hambatan throughput yang disebabkan oleh paralelisme yang tidak memadai. Bottleneck ini dapat menyebabkan pipeline berjalan lambat atau macet.
    • Metrik Keterlambatan sistem (system_lag) dan metrik keterlambatan sistem per tahap (per_stage_system_lag) mengukur jumlah waktu maksimum item data diproses atau menunggu pemrosesan. Gunakan metrik ini untuk mengidentifikasi tahap yang tidak efisien dan hambatan dari sumber data.

Untuk metrik tambahan yang tidak disertakan dalam antarmuka web pemantauan Dataflow, lihat daftar lengkap metrik Dataflow di Google Cloud metrik.