Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Pertumbuhan negara tak terbatas
Jika aplikasi Anda tidak membuang informasi status yang tidak berlaku dengan benar, informasi akan terus diakumulasi dan menyebabkan masalah performa atau stabilitas aplikasi. Bagian ini menjelaskan gejala dan langkah pemecahan masalah untuk kondisi ini.
## Gejala
Kondisi ini dapat memiliki gejala berikut:
+ Metrik `lastCheckpointDuration` meningkat atau melonjak secara bertahap.
+ Metrik `lastCheckpointSize` meningkat atau melonjak secara bertahap.
## Penyebab dan solusi
Kondisi berikut dapat menyebabkan aplikasi Anda mengakumulasi data status:
+ Aplikasi Anda menyimpan data status lebih lama dari yang dibutuhkan.
+ Aplikasi Anda menggunakan kueri jendela dengan durasi yang terlalu lama.
+ Anda tidak menetapkan TTL untuk data status Anda. Untuk informasi selengkapnya, lihat [Status Time-To-Live (TTL) di Dokumentasi](https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/dev/datastream/fault-tolerance/state/#state-time-to-live-ttl) Apache Flink.
+ Anda menjalankan aplikasi yang bergantung pada Apache Beam versi 2.25.0 atau yang lebih baru. Anda dapat memilih keluar dari versi baru transformasi baca dengan [memperluas eksperimen dan nilai `use_deprecated_read` utama Anda BeamApplicationProperties](https://docs.aws.amazon.com/managed-flink/latest/java/examples-beam.html#examples-beam-configure). Untuk informasi selengkapnya, lihat [Dokumentasi Apache Beam](https://beam.apache.org/blog/beam-2.25.0/#highlights).
Terkadang aplikasi menghadapi pertumbuhan ukuran negara yang terus berkembang, yang tidak berkelanjutan dalam jangka panjang (bagaimanapun juga aplikasi Flink berjalan tanpa batas waktu). Terkadang, ini dapat ditelusuri kembali ke aplikasi yang menyimpan data dalam keadaan dan tidak menua informasi lama dengan benar. Tapi terkadang hanya ada harapan yang tidak masuk akal tentang apa yang bisa diberikan Flink. Aplikasi dapat menggunakan agregasi selama jendela waktu besar yang mencakup hari atau bahkan berminggu-minggu. Kecuali [AggregateFunctions](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/windows/#aggregatefunction)digunakan, yang memungkinkan agregasi inkremental, Flink perlu menjaga peristiwa seluruh jendela dalam keadaan.
Selain itu, ketika menggunakan fungsi proses untuk mengimplementasikan operator kustom, aplikasi perlu menghapus data dari status yang tidak lagi diperlukan untuk logika bisnis. Dalam hal ini, [status time-to-live](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/fault-tolerance/state/#state-time-to-live-ttl) dapat digunakan untuk secara otomatis menua data berdasarkan waktu pemrosesan. [Layanan Terkelola untuk Apache Flink menggunakan pos pemeriksaan tambahan dan dengan demikian status ttl didasarkan pada pemadatan RocksDB.](https://github.com/facebook/rocksdb/wiki/Compaction) Anda hanya dapat mengamati pengurangan aktual dalam ukuran status (ditunjukkan oleh ukuran pos pemeriksaan) setelah operasi pemadatan terjadi. Khususnya untuk ukuran pos pemeriksaan di bawah 200 MB, kecil kemungkinan Anda mengamati pengurangan ukuran pos pemeriksaan sebagai akibat dari keadaan kedaluwarsa. Namun, savepoints didasarkan pada salinan bersih dari status yang tidak berisi data lama, sehingga Anda dapat memicu snapshot di Managed Service for Apache Flink untuk memaksa penghapusan status usang.
Untuk tujuan debugging, masuk akal untuk menonaktifkan pos pemeriksaan tambahan untuk memverifikasi lebih cepat bahwa ukuran pos pemeriksaan benar-benar berkurang atau stabil (dan menghindari efek pemadatan di RocksBS). Namun, ini membutuhkan tiket ke tim layanan.