Timeout checkpoint dan savepoint terjadi selama salah satu dari dua fase dalam proses checkpointing: penyelarasan barrier yang lambat (fase sinkron) atau pengunggahan state yang lambat (fase asinkron). Topik ini menjelaskan cara mengidentifikasi fase bottleneck dan menerapkan metode penyetelan yang sesuai.
Fase checkpoint
Realtime Compute for Apache Flink menggunakan algoritma Chandy-Lamport untuk manajemen state, memastikan konsistensi data dan keandalan. Setiap checkpoint atau savepoint melewati dua fase:
Fase sinkron — Sistem menunggu barrier menyelaraskan di seluruh operator. Barrier adalah jenis khusus catatan data yang dilewatkan antar operator. Waktu yang dibutuhkan untuk penyelarasan barrier sebanding dengan keterlambatan kedatangan catatan data.
Fase asinkron — Setiap operator mengunggah state lokalnya ke sistem penyimpanan persisten remote. Waktu unggah sebanding dengan ukuran state.
Tekanan balik (backpressure) memperlambat propagasi barrier selama fase sinkron, yang secara langsung menyebabkan timeout checkpoint dan savepoint. Atasi tekanan balik sebelum menyelidiki masalah timeout. Untuk panduan, lihat Kontrol ukuran state untuk mengurangi backpressure dalam penerapan SQL dan Kontrol ukuran state untuk mengurangi backpressure menggunakan DataStream API.
Identifikasi fase bottleneck
Setelah mengatasi tekanan balik, jika checkpoint atau savepoint masih mengalami timeout, gunakan alat berikut untuk menentukan apakah bottleneck terjadi di fase sinkron atau fase asinkron.
UI riwayat Checkpoint
Navigasi ke O&M > Deployments, klik nama deployment target, lalu buka Logs > Checkpoints > Checkpoints History. Tampilan ini menyediakan metrik tingkat deployment, tingkat operator, dan tingkat subtask.
Identifikasi operator tempat checkpoint mengalami timeout atau masih dalam proses, lalu periksa metrik berikut:
| Metric | Description |
|---|---|
| Sync Duration | Total waktu yang dihabiskan dalam fase sinkron, termasuk snapshotting state operator. |
| Alignment Duration | Waktu antara pemrosesan barrier checkpoint pertama dan terakhir. Nilai tinggi mengindikasikan distribusi data yang tidak merata di saluran input. |
| Async Duration | Waktu yang dihabiskan untuk mengunggah state ke penyimpanan remote. |
| Checkpointed Data Size | Volume data state yang ditulis selama checkpoint. |
Cara menginterpretasikan hasil:
Sync Duration atau Alignment Duration tinggi — Bottleneck berada di fase sinkron. Barrier bergerak lambat melalui graf pekerjaan, biasanya disebabkan oleh sisa tekanan balik atau skew saluran.
Async Duration atau Checkpointed Data Size tinggi — Bottleneck berada di fase asinkron. State terlalu besar untuk diunggah dalam jendela timeout.
Metrik checkpoint
Navigasi ke O&M > Deployments, klik nama deployment target, lalu buka tab Logs dan klik Alarm. Metrik lastCheckpointDuration dan lastCheckpointSize memberikan gambaran kasar tentang performa historis checkpoint, berguna untuk mengidentifikasi tren dari waktu ke waktu.
Optimalkan performa checkpoint dan savepoint
Sebelum menerapkan metode penyetelan apa pun, pastikan performa runtime deployment memenuhi ekspektasi. Performa runtime yang buruk memperparah masalah checkpoint. Setelah mengoptimalkan performa runtime, terapkan satu atau beberapa metode berikut berdasarkan fase bottleneck.
Metode-metode ini tidak saling eksklusif. Gabungkan jika deployment mengalami bottleneck di kedua fase.
Gunakan checkpoint unaligned dan buffer debloating
| Property | Details |
|---|---|
| Kapan digunakan | Timeout checkpoint atau savepoint disebabkan oleh fase sinkron |
| Cara membantu | Menghilangkan kebutuhan penyelarasan barrier, menyelesaikan masalah timeout terkait barrier yang lambat atau skew. Efektif untuk deployment dalam semua ukuran. |
| Konfigurasi | Lihat Checkpointing under backpressure dalam dokumentasi Apache Flink. |
Checkpoint unaligned memiliki batasan tertentu. Tinjau bagian Limitations dalam dokumentasi Apache Flink sebelum mengaktifkan fitur ini.
Tingkatkan parallelism
| Property | Details |
|---|---|
| Kapan digunakan | Timeout checkpoint atau savepoint disebabkan oleh fase asinkron |
| Cara membantu | Mendistribusikan data state ke lebih banyak task paralel, sehingga mengurangi jumlah data yang diunggah setiap task selama fase asinkron. |
| Konfigurasi | Sesuaikan parallelism menggunakan mode dasar atau ahli pada konfigurasi resource. Lihat Konfigurasikan resource untuk deployment. |
Gunakan format native untuk savepoint
| Property | Details |
|---|---|
| Kapan digunakan | Timeout savepoint disebabkan oleh fase asinkron |
| Cara membantu | Format native menghasilkan savepoint lebih cepat dan mengonsumsi lebih sedikit storage space dibandingkan format standar. |
| Konfigurasi | Buat savepoint dalam format native untuk deployment yang sedang berjalan. Lihat bagian "Manually create a savepoint" dalam Manajemen status set. |
Savepoint dalam format native tidak menjamin kompatibilitas lintas versi mayor Flink. Jika diperlukan kompatibilitas lintas versi, gunakan format standar sebagai gantinya.
Referensi
Penyetelan performa untuk deployment state besar — Membahas isu yang disebabkan oleh ukuran state besar dan alur kerja penyetelan secara keseluruhan.
Kontrol ukuran state untuk mengurangi backpressure dalam penerapan SQL — Menjelaskan bagaimana pengoptimal Flink SQL memilih operator stateful, dan cara menyetel komputasi stateful pada dataset besar.
Kontrol ukuran state untuk mengurangi backpressure menggunakan DataStream API — Membahas manajemen ukuran state yang fleksibel dengan DataStream API.
Tingkatkan kecepatan startup dan scaling — Saat me-restart deployment dari checkpoint atau savepoint, data state diunduh dari penyimpanan remote untuk memulihkan mesin state. Proses ini dapat menjadi bottleneck efisiensi. Lihat topik ini untuk panduan mengidentifikasi dan menghilangkan bottleneck performa selama startup dan scaling deployment.