Memecahkan masalah tugas yang lambat atau macet

Halaman ini menjelaskan cara memecahkan masalah penyebab umum streaming dan tugas batch Dataflow yang lambat atau macet.

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, artinya pipeline macet dan tidak berkembang.
    • Jika keaktualan data meningkat, tetapi byte backlog tetap normal, artinya satu atau beberapa item pekerjaan macet di pipeline.

    Cari tahap saat metrik ini meningkat, untuk mengidentifikasi tahap yang mengalami masalah dan operasi yang dilakukan di tahap tersebut.

  2. Periksa Diagram pemrosesan paralel untuk melihat apakah ada tahap yang macet karena paralelisme yang rendah. Lihat Memecahkan masalah paralelisme.

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

  4. Periksa log pekerja untuk menemukan peringatan dan error.

    • 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 melebihi batas, seperti ukuran pesan Pub/Sub maksimum.
    • Mencari error kehabisan memori, yang dapat menyebabkan pipeline macet. Jika Anda melihat error kekurangan memori, ikuti langkah-langkah di Memecahkan masalah error kekurangan memori Dataflow.
    • Untuk mengidentifikasi langkah yang lambat atau macet, periksa log pekerja untuk menemukan 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 pekerjaan macet di pekerja tertentu, mulai ulang VM pekerja tersebut.

  6. Jika Anda tidak menggunakan Streaming Engine, periksa log shuffler untuk menemukan 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 pintasan.

  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 akan dicoba ulang tanpa batas waktu. Percobaan ulang ini mencegah pipeline untuk maju. Untuk mengidentifikasi kegagalan berulang, periksa pengecualian di log pekerja.

Mengidentifikasi pekerja yang tidak responsif

Jika pekerja yang memproses tugas streaming tidak sehat, tugas tersebut mungkin lambat atau tampak macet. Untuk mengidentifikasi pekerja yang tidak responsif:

Mengidentifikasi straggler

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

Memecahkan masalah paralelisme yang tidak memadai

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

  • Kunci ditentukan secara implisit oleh properti sumber, seperti partisi Pub/Sub.
  • Kunci ditentukan secara eksplisit oleh logika agregasi dalam pipeline, seperti GroupByKey.

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

Mengidentifikasi tahap dengan paralelisme rendah

Untuk mengidentifikasi apakah kelambatan pipeline disebabkan oleh paralelisme yang rendah, lihat metrik penggunaan CPU. Jika CPU rendah tetapi didistribusikan secara merata di seluruh pekerja, tugas Anda mungkin tidak memiliki paralelisme yang memadai. Jika tugas Anda menggunakan Streaming Engine, untuk melihat apakah suatu tahap memiliki paralelisme yang 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 adalah masalahnya, lihat Memecahkan masalah penskalaan otomatis Dataflow.
  • Gunakan grafik tugas untuk memeriksa langkah-langkah dalam tahap. Jika tahap membaca dari sumber atau menulis ke sink, tinjau dokumentasi untuk layanan sumber atau sink. Gunakan dokumentasi untuk menentukan apakah layanan tersebut dikonfigurasi untuk skalabilitas yang memadai.

Memeriksa hotkey

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

Periksa tombol pintasan 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:

  • Mengganti kunci enkripsi data Anda. Untuk menghasilkan key-value pair baru, terapkan transformasi ParDo. Untuk 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 class Combine.PerKey di Java SDK atau operasi with_hot_key_fanout di Python SDK.
  • Jika Anda memiliki pipeline Java yang memproses PCollections tak terbatas dalam volume 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 sink. Misalnya, jika pipeline Anda membaca input dari Pub/Sub atau BigQuery, project Google Cloud Anda mungkin tidak memiliki kuota yang memadai. Untuk mengetahui informasi selengkapnya tentang batas kuota untuk layanan ini, lihat Kuota Pub/Sub atau Kuota BigQuery.

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

  1. Buka Konsol Google Cloud.
  2. Di panel navigasi, klik API & layanan.
  3. Di menu, klik Library.
  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 sink 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 Select a metric, untuk Metric, filter ke BigQuery Project > Write > concurrent connection count.

Untuk mengetahui petunjuk tentang cara melihat metrik Pub/Sub, lihat Memantau penggunaan kuota di "Memantau Pub/Sub di Cloud Monitoring". Untuk 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 bottleneck.

Mengidentifikasi akar masalah

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

    Untuk memverifikasi bahwa tugas telah mulai memproses data, lihat log job-message untuk menemukan entri log 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 Dataflow Shuffle sama.

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

  4. Di tab Execution details, bandingkan progres stage untuk mengidentifikasi stage yang memerlukan waktu lebih lama.

  5. Cari tugas yang tertinggal dalam tugas. Untuk informasi selengkapnya, lihat Memecahkan masalah straggler dalam tugas batch.

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

  7. Periksa log pekerja untuk menemukan peringatan dan error.

  8. Periksa tombol pintasan.

  9. Jika Anda tidak menggunakan Dataflow Shuffle, periksa log shuffler untuk menemukan peringatan dan error selama operasi shuffle. 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 straggler

Item lambat adalah item pekerjaan yang lambat dibandingkan dengan item pekerjaan lainnya dalam tahap. Untuk mengetahui informasi tentang cara mengidentifikasi dan memperbaiki straggler, lihat Memecahkan masalah straggler 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 memerlukan lebih banyak waktu. Gunakan tampilan ini untuk mengidentifikasi tahap paling lambat dalam pipeline Anda.

Setelah menemukan tahap bottleneck, 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 bottleneck paralelisme, gunakan Metrik pemantauan aliran data.

Mengidentifikasi pekerja yang lambat

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

Alat untuk proses debug

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

  • Untuk mengaitkan insiden dan mengidentifikasi bottleneck, 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 dalam pipeline batch atau streaming.
  • Untuk mempelajari tugas yang macet lebih lanjut, gunakan Metrik tugas Dataflow. Daftar berikut mencakup metrik yang berguna:
    • Metrik Backlog byte (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 pipeline tertentu 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.
      • Temukan bottleneck throughput yang disebabkan oleh paralelisme yang tidak memadai. Bottleneck ini dapat menyebabkan pipeline lambat atau macet.
    • Metrik Latensi sistem (system_lag) dan metrik latensi sistem per tahap (per_stage_system_lag) mengukur jumlah waktu maksimum item data telah diproses atau menunggu pemrosesan. Gunakan metrik ini untuk mengidentifikasi bottleneck dan tahap yang tidak efisien dari sumber data.

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