Memecahkan masalah tugas yang lambat atau macet

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

Streaming

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

• 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 ini untuk mengidentifikasi dan mendiagnosis masalah.

Menyelidiki kegagalan berulang

Dalam tugas streaming, beberapa kegagalan dicoba lagi tanpa batas. Percobaan ulang ini mencegah progres pipeline. Untuk mengidentifikasi kegagalan berulang, periksa pengecualian log pekerja.

• Jika pengecualian terjadi pada kode pengguna, debug dan perbaiki masalah dalam kode atau dalam data.
• Untuk mencegah kegagalan tak terduga menghambat pipeline Anda, terapkan antrean yang dihentikan pengirimannya. Untuk contoh implementasi, 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 tidak sehat

Jika pekerja yang memproses tugas streaming tidak responsif, pekerjaan mungkin berjalan lambat atau terhenti. Untuk mengidentifikasi pekerja tidak sehat:

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

Mengidentifikasi orang yang kesulitan

Straggler adalah item tugas yang lambat dibandingkan dengan item tugas lainnya dalam tahap. Untuk informasi tentang cara mengidentifikasi dan memperbaiki pengguna yang lambat, lihat Memecahkan masalah orang yang monoton dalam tugas streaming.

Memecahkan masalah paralelisme yang tidak memadai

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

• Kunci secara implisit ditetapkan oleh properti sumber, seperti partisi Pub/Sub.
• Kunci secara eksplisit ditentukan 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 hambatan.

Mengidentifikasi tahapan dengan paralelisme yang rendah

Untuk mengidentifikasi apakah kelambatan pipeline disebabkan oleh paralelisme yang rendah, lihat metrik pemakaian CPU. Jika CPU rendah tetapi didistribusikan secara merata ke seluruh pekerja, tugas Anda mungkin memiliki paralelisme yang tidak memadai. Jika tugas Anda menggunakan Streaming Engine, untuk melihat apakah 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 Autoscaling untuk melihat apakah tugas mengalami masalah peningkatan skala. Jika penskalaan otomatis menjadi 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 mendapatkan 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 informasi selengkapnya, lihat dokumentasi Apache Kafka.
  • Jika Anda menggunakan sink BigQuery, aktifkan sharding otomatis untuk meningkatkan paralelisme. Untuk mengetahui informasi selengkapnya, lihat Throughput Dataflow 3x dengan Sharding Otomatis untuk BigQuery.

Memeriksa hot key

Jika tugas didistribusikan secara tidak merata ke seluruh pekerja dan pemanfaatan pekerja sangat tidak merata, pipeline Anda mungkin memiliki hot key. {i>Hot key<i} adalah kunci yang memiliki lebih banyak elemen untuk diproses dibandingkan dengan kunci lain. Untuk mengatasi masalah ini, lakukan satu atau beberapa langkah berikut:

• Kunci ulang data Anda. Untuk menghasilkan output 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. 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 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 sink. Misalnya, jika pipeline Anda membaca input dari Pub/Sub atau BigQuery, project Google Cloud Anda mungkin tidak memiliki kuota yang cukup. 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 cukup. Untuk memeriksa error, coba langkah-langkah berikut:

1. Buka Konsol Google Cloud.
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 Manage.
7. Di diagram Traffic menurut kode respons, cari kode error klien (4xx).

Anda juga dapat menggunakan Metrics Explorer untuk memeriksa penggunaan kuota. Jika pipeline Anda menggunakan sumber atau sink BigQuery, gunakan metrik BigQuery Storage API untuk memecahkan masalah kuota. Misalnya, untuk membuat diagram yang menunjukkan 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 bagian "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 terhenti, gunakan tab Detail eksekusi untuk menemukan informasi selengkapnya tentang tugas dan untuk mengidentifikasi tahap atau pekerja yang menyebabkan bottleneck.

Mengidentifikasi orang yang kesulitan

Straggler adalah item tugas yang lambat dibandingkan dengan item tugas lainnya dalam tahap. Untuk informasi tentang mengidentifikasi dan memperbaiki pekerja yang lambat, lihat Memecahkan masalah orang yang kesulitan dalam tugas batch.

Mengidentifikasi tahapan yang lambat atau macet

Untuk mengidentifikasi tahapan yang lambat atau macet, gunakan tampilan Stage progress. Batang yang lebih panjang menunjukkan bahwa tahap membutuhkan lebih banyak waktu. Gunakan tampilan ini untuk mengidentifikasi tahap paling lambat di pipeline Anda.

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

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

Mengidentifikasi pekerja yang mengalami lag

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

• Melihat file log untuk pekerja tersebut. Untuk mengetahui informasi selengkapnya, lihat Memantau dan melihat log pipeline.
• Lihat metrik pemanfaatan CPU dan detail progres pekerja untuk pekerja yang mengalami keterlambatan. Jika Anda melihat pemakaian 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 masalahnya.

• Untuk menghubungkan 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 terhenti di pipeline batch atau streaming.
• Untuk mempelajari lebih lanjut tugas yang macet, gunakan Metrik tugas Dataflow. Daftar berikut mencakup metrik yang berguna:
  • Metrik Byte backlog (backlog_bytes) mengukur jumlah input yang belum diproses dalam byte berdasarkan tahapan. 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 sebuah tahap.
  • Metrik Pemrosesan kunci paralelisme (processing_parallelism_keys) mengukur jumlah kunci pemrosesan paralel untuk tahap tertentu pada pipeline selama lima menit terakhir. Gunakan metrik ini untuk melakukan penyelidikan dengan cara berikut:
    • Persempit masalah ke tahap tertentu dan konfirmasi peringatan hot key, seperti A hot key ... was detected.
    • Menemukan bottleneck throughput yang disebabkan oleh paralelisme yang tidak memadai. Hambatan ini dapat mengakibatkan pipeline yang lambat atau macet.
  • Metrik Jeda 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 tahapan 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 metrik Google Cloud.