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:

• 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.

Menyelidiki kegagalan berulang

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

• Jika pengecualian terjadi pada kode pengguna, debug dan perbaiki masalah dalam kode atau dalam data.
• Untuk mencegah kegagalan yang tidak terduga agar tidak menghambat pipeline Anda, terapkan antrean surat mati. Untuk contoh penerapan, lihat pola BigQuery dalam dokumentasi Apache Beam.
• Jika pengecualian 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 sehat, tugas tersebut mungkin lambat atau tampak macet. Untuk mengidentifikasi pekerja yang tidak responsif:

• Periksa tekanan memori menggunakan metrik penggunaan memori dan dengan mencari error kehabisan memori dalam log pekerja. Untuk mengetahui informasi selengkapnya, lihat Memecahkan masalah error Dataflow kehabisan memori.
• Jika Anda menggunakan Streaming Engine, gunakan metrik persistensi untuk mengidentifikasi bottleneck pada operasi input/output disk (IOPS).
• Periksa log pekerja untuk menemukan error lainnya. Untuk mengetahui informasi selengkapnya, lihat Menggunakan log pipeline dan Memecahkan masalah error Dataflow.

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 tahap memiliki paralelisme yang rendah, lihat metrik paralelisme di tab Metrik Tugas. 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.
  • Untuk mengumpulkan informasi selengkapnya, gunakan metrik input dan output yang disediakan oleh Dataflow.
  • Jika Anda menggunakan Kafka, periksa jumlah partisi Kafka. Untuk mengetahui informasi selengkapnya, lihat dokumentasi Apache Kafka.
  • Jika Anda menggunakan sink BigQuery, aktifkan sharding otomatis untuk meningkatkan paralelisme. Untuk informasi selengkapnya, lihat 3x Dataflow Throughput dengan Pembagian Otomatis untuk BigQuery.

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. Untuk mengatasi masalah ini, lakukan satu atau beberapa langkah berikut:

• Mengganti kunci enkripsi data Anda. Untuk menghasilkan pasangan nilai kunci 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 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 lambat atau macet, gunakan tab Detail eksekusi untuk menemukan informasi selengkapnya tentang tugas dan mengidentifikasi tahap atau pekerja yang menyebabkan bottleneck.

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:

• Lihat file log untuk pekerja tersebut. Untuk mengetahui informasi selengkapnya, lihat Memantau dan melihat log pipeline.
• Lihat metrik penggunaan CPU dan detail progres pekerja untuk pekerja yang tertinggal. Jika Anda melihat penggunaan CPU yang sangat tinggi atau rendah, dalam file log untuk pekerja tersebut, cari masalah berikut:
  • A hot key ... was detected
  • Processing stuck ... Operation ongoing

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 pintasan, 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 metrik Google Cloud.