Memecahkan masalah tugas streaming yang lambat atau macet

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

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

  • Pipeline tidak membaca data dari sumber. Misalnya, Pub/Sub memiliki backlog yang terus bertambah.
  • Pipeline tidak menulis data ke sink.
  • Metrik keaktualan data meningkat.
  • Metrik latensi sistem meningkat.

Gunakan informasi di bagian berikut untuk mengidentifikasi dan mendiagnosis masalah.

Mengidentifikasi akar penyebab

  1. Periksa metrik keaktualan data dan byte backlog.

    • Jika kedua metrik meningkat secara monoton, artinya 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 tempat 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 mencukupi. Lihat Memecahkan masalah paralelisme.

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

  4. Periksa log pekerja untuk mengetahui peringatan dan error.

    • Jika log pekerja berisi error, lihat pelacakan stack. 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.
    • Cari error kehabisan memori, yang dapat menyebabkan pipeline macet. Jika Anda melihat error kehabisan memori, ikuti langkah-langkah di Memecahkan masalah error kehabisan memori Dataflow.
    • Untuk mengidentifikasi langkah yang lambat atau macet, periksa log pekerja untuk mengetahui pesan Operation ongoing. Lihat pelacakan stack 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 shuffler 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 kunci aktif.

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

Menyelidiki kegagalan berulang

Dalam tugas streaming, beberapa kegagalan akan dicoba ulang tanpa batas. Percobaan ulang ini mencegah pipeline berjalan. Untuk mengidentifikasi kegagalan berulang, periksa log pekerja untuk mengetahui pengecualian.

  • Jika pengecualiannya adalah kode pengguna, lakukan proses debug dan perbaiki masalah dalam kode atau dalam data.
  • Untuk mencegah kegagalan yang tidak terduga menghentikan pipeline Anda, terapkan antrean pesan yang tidak terkirim. Untuk contoh penerapan, lihat pola BigQuery dalam dokumentasi Apache Beam.
  • Jika pengecualiannya adalah error kehabisan memori (OOM), lihat Memecahkan masalah error kehabisan memori Dataflow.
  • Untuk pengecualian lainnya, lihat Memecahkan masalah error Dataflow.

Mengidentifikasi pekerja yang tidak responsif

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

Mengidentifikasi pekerja yang tertinggal

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

Memecahkan masalah paralelisme

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 secara implisit ditentukan oleh properti sumber, seperti partisi Kafka.
  • Kunci secara eksplisit ditentukan oleh logika agregasi dalam pipeline, seperti GroupByKey.

Di Dataflow, thread pekerja bertanggung jawab untuk menangani pemrosesan paket kerja (pesan) untuk 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 pekerjaan (batch atau streaming).

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

Jika pipeline menggunakan kunci dalam jumlah yang sangat besar untuk tahap tertentu, pipeline dapat membatasi throughput tahap tersebut dan mengakumulasikan backlog di tahap hulu, karena ada overhead per kunci. Overhead dapat mencakup backend yang berkomunikasi dengan 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 mungkin 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 mencukupi. Jika tugas Anda menggunakan Streaming Engine, untuk melihat apakah suatu tahap memiliki paralelisme rendah, di tab Job Metrics, lihat metrik paralelisme. Untuk mengurangi masalah ini:

  • Di Google Cloud konsol, di halaman Job info, gunakan tab Autoscaling untuk melihat apakah tugas mengalami masalah dalam meningkatkan skala. 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.

Mengidentifikasi tahap dengan paralelisme tinggi

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

Transformasi seperti Reshuffle dapat menghasilkan jutaan kunci jika Anda tidak secara eksplisit menentukan withNumBuckets. Jumlah kunci yang besar 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 kunci pemrosesan yang signifikan, sehingga menyebabkan penundaan saat 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 (threads_per_worker * max_workers) kunci dalam pipeline mungkin tidak optimal. Terkadang, kunci yang lebih sedikit dan paket yang lebih besar dapat diproses, dan diproses lebih efisien oleh Dataflow karena menggunakan lebih sedikit pekerja. Jumlah kunci yang lebih kecil membuat paket kerja yang lebih besar, yang menggunakan thread pekerja secara efisien dan meningkatkan throughput tahap.

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

Memeriksa kunci aktif

Jika tugas didistribusikan secara tidak merata di seluruh pekerja dan penggunaan pekerja sangat tidak merata, pipeline Anda mungkin memiliki kunci aktif. Kunci aktif adalah kunci yang terlalu banyak direpresentasikan dalam data.

Periksa apakah pipeline Anda memiliki kunci aktif dengan melihat status Bottleneck untuk langkah yang lambat. Anda mungkin memiliki kunci aktif jika alasan bottleneck adalah "Hot keys or insufficient key parallelism". Untuk mengetahui informasi umum tentang bottleneck, lihat Memecahkan masalah bottleneck.

Secara default, Dataflow hanya mencatat keberadaan kunci aktif, bukan nilai kunci tertentu. Untuk mencetak kunci yang dapat dibaca manusia ke log saat kunci aktif terdeteksi, tetapkan opsi pipeline proses debug berikut saat Anda menjalankan pipeline:

Java

--hotKeyLoggingEnabled=true

Python

--dataflow_service_options=enable_hot_key_logging

Jika Anda menjalankan tugas Template Flex, lihat Menentukan opsi pipeline untuk mengetahui informasi selengkapnya tentang penggunaan --additional-pipeline-options untuk meneruskan opsi.

Kemudian, periksa kunci aktif menggunakan filter log berikut:

  resource.type="dataflow_step"
  resource.labels.job_id=JOB_ID
  jsonPayload.logger="org.apache.beam.runners.dataflow.worker.HotKeyLogger"

Ganti JOB_ID dengan ID tugas Anda.

Anda juga dapat mengonfigurasi pemberitahuan berbasis log untuk memberi tahu Anda saat kunci aktif terdeteksi di pipeline. Gunakan filter contoh sebagai titik awal.

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

  • Ubah kunci data Anda. Untuk menampilkan key-value pair baru, terapkan transformasi ParDo. Untuk mengetahui informasi selengkapnya, lihat halaman transformasi Java ParDo atau halaman transformasi Python ParDo dalam dokumentasi Apache Beam.
  • Gunakan .withFanout dalam transformasi gabungan. Untuk mengetahui informasi selengkapnya, lihat Combine.PerKey class di Java SDK atau with_hot_key_fanout operasi di Python SDK.
  • Jika Anda memiliki pipeline Java yang memproses PCollections tanpa batas dengan volume tinggi, sebaiknya lakukan hal berikut:
    • Gunakan Combine.Globally.withFanout dan bukan Combine.Globally.
    • Gunakan Combine.PerKey.withHotKeyFanout dan 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, 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 error 429 (Rate Limit Exceeded) dalam jumlah yang tinggi, tugas tersebut mungkin memiliki kuota yang tidak mencukupi. Untuk memeriksa error, coba langkah-langkah berikut:

  1. Buka Google Cloud konsol.
  2. Di panel navigasi, klik API &layanan.
  3. Di menu, klik Koleksi.
  4. Gunakan kotak penelusuran untuk menelusuri Pub/Sub.
  5. Klik Cloud Pub/Sub API.
  6. Klik Kelola.
  7. Di 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 Google Cloud konsol, 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 mengetahui petunjuk tentang cara melihat metrik BigQuery, lihat Melihat penggunaan dan batas kuota di "Membuat dasbor, diagram, dan pemberitahuan".

Alat untuk proses debug

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

  • Untuk mengorelasikan insiden dan mengidentifikasi bottleneck, gunakan Cloud Monitoring untuk Dataflow.
  • Untuk memantau performa pipeline, gunakan Cloud Profiler.
  • Beberapa transformasi lebih cocok untuk pipeline dengan volume tinggi daripada yang lain. Pesan log dapat mengidentifikasi transformasi pengguna yang macet di pipeline batch atau streaming.
  • Untuk mempelajari tugas yang macet lebih lanjut, gunakan metrik tugas Dataflow. Daftar berikut mencakup metrik yang berguna:
    • Metrik Backlog bytes (backlog_bytes) mengukur jumlah input yang belum diproses dalam byte berdasarkan 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 Processing parallelism keys (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 kunci aktif, seperti A hot key ... was detected.
      • Temukan bottleneck throughput yang disebabkan oleh paralelisme yang tidak mencukupi. Bottleneck ini dapat menyebabkan pipeline lambat atau macet.
    • Metrik System lag (system_lag) dan metrik system lag per tahap (per_stage_system_lag) mengukur jumlah waktu maksimum item data telah diproses atau menunggu pemrosesan. Gunakan metrik ini untuk mengidentifikasi tahap dan bottleneck 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 metrik.