Pengumpulan sampah di Amazon DocumentDB

Amazon DocumentDB mengimplementasikan arsitektur database kontrol konkurensi multi-versi (MVCC) yang membuat versi baru entri dokumen dan indeks untuk setiap operasi pembaruan. Arsitektur ini menyediakan isolasi baca dengan memungkinkan kueri baca untuk menggunakan dokumen berversi tanpa mengambil kunci.

Memahami Pengumpulan Sampah di Amazon DocumentDB

Pengumpulan sampah (GC) adalah proses latar belakang otomatis yang mempertahankan kinerja dan ketersediaan sistem yang optimal di Amazon DocumentDB. Tidak seperti database tradisional yang menimpa data di tempat, arsitektur MVCC Amazon DocumentDB membuat versi baru dokumen dan entri indeks dengan setiap operasi pembaruan. Setiap operasi tulis yang menghasilkan versi dokumen baru menggunakan ID MVCC unik dari penghitung terbatas, membuat pembersihan yang efisien menjadi penting. Seiring waktu, versi lama ini menumpuk dan harus dibersihkan untuk mencegah penurunan kinerja.

Fungsi pengumpulan sampah

Pengumpul sampah melayani tiga fungsi penting:

• Mendapatkan kembali ruang penyimpanan - Ini menghapus dokumen usang dan versi indeks yang tidak lagi diperlukan oleh kueri aktif, membebaskan ruang untuk operasi penulisan di masa depan.

• Mencegah luapan ID MVCC — Ini mencegah luapan ID MVCC dengan mengelola penghitung terbatas MVCC. IDs Tanpa manajemen ini, penghitung pada akhirnya akan mencapai batasnya, memaksa database ke mode read-only sementara sampai IDs didaur ulang.

• Mempertahankan kinerja kueri — Ini mempertahankan kinerja kueri yang optimal dengan menghilangkan versi dokumen mati yang jika tidak akan menumpuk dan memperlambat pemrosesan kueri.

Proses pengumpulan sampah

Proses GC beroperasi per koleksi dan dapat memiliki beberapa proses yang berjalan bersamaan pada koleksi yang berbeda. Prosesnya terdiri dari empat fase berurutan:

1. Identifikasi — Sistem mengidentifikasi versi dokumen dan indeks yang tidak lagi direferensikan oleh transaksi atau kueri aktif.

2. Memory loading — Dokumen lama dan entri indeks dimuat ke dalam memori jika belum ada.

3. Penghapusan - Versi usang dihapus secara permanen untuk merebut kembali ruang penyimpanan.

4. Daur ulang ID MVCC — Sistem mendaur ulang MVCC IDs dari versi yang dihapus untuk operasi baru.

Ketika pengumpulan sampah selesai memproses versi dokumen lama, ia menghapus MVCC tertua IDs dari sistem. Pembersihan ini sangat penting untuk mencegah luapan ID MVCC dengan mendaur ulang MVCC IDs, membuatnya tersedia untuk operasi penulisan baru di seluruh cluster. Tanpa proses daur ulang ini, sistem pada akhirnya akan menghabiskan penghitung ID MVCC yang terbatas dan memasuki status hanya-baca.

Penjadwalan pengumpulan sampah

Pengumpulan sampah berjalan secara otomatis di latar belakang pada interval berkala. Waktu dan frekuensi menyesuaikan secara dinamis berdasarkan beban sistem, sumber daya yang tersedia, volume tulis, dan tingkat konsumsi ID MVCC. Selama aktivitas tulis tinggi, proses GC mengeksekusi lebih sering untuk mengelola peningkatan jumlah versi dokumen.

Memantau pengumpulan sampah

Metrik tingkat cluster

AvailableMVCCIds

• Lokasi - Amazon CloudWatch

• Deskripsi — Penghitung yang menunjukkan jumlah operasi penulisan yang tersisa yang tersedia sebelum mencapai nol. Saat penghitung ini mencapai nol, klaster Anda memasuki mode hanya-baca hingga direklamasi dan IDs didaur ulang. Penghitung berkurang dengan setiap operasi penulisan dan meningkat saat pengumpulan sampah mendaur ulang IDs MVCC lama.

• Rekomendasi — Atur alarm saat nilainya turun di bawah 1,3 miliar. Peringatan dini ini memungkinkan Anda untuk mengambil langkah-langkah yang disarankan dibahas nanti.

LongestRunningGCProcess

• Lokasi - Amazon CloudWatch

• Deskripsi — Durasi dalam hitungan detik dari proses pengumpulan sampah aktif terpanjang. Memperbarui setiap menit dan hanya melacak operasi aktif, tidak termasuk proses yang selesai dalam jendela satu menit.

• Rekomendasi —

Metrik tingkat pengumpulan

MVCCIDStats: MvccIdAgeScale

• Lokasi - Perintah CollStats Database

• Deskripsi — Mengukur usia ID MVCC pada skala 0 hingga 1, di mana 1 menunjukkan usia maksimum sebelum klaster memasuki status hanya-baca. Gunakan metrik ini bersama AvailableMVCCIds untuk mengidentifikasi koleksi yang berisi MVCC tertua IDs yang menua cluster.

• Rekomendasi - Pertahankan nilai di bawah 0,3 untuk setiap koleksi.

GCRuntimeStats

• Lokasi - Perintah CollStats Database

• Deskripsi — Memberikan riwayat metrik pengumpulan sampah selama dua bulan, termasuk total proses, durasi rata-rata, dan durasi maksimum. Hanya mencakup operasi pengumpulan sampah yang berlangsung lebih dari lima menit untuk memastikan statistik yang berarti.

UnusedStorageSize(tingkat pengumpulan)

• Lokasi - Perintah CollStats Database

• Deskripsi — Memperkirakan ruang penyimpanan yang tidak digunakan dalam koleksi berdasarkan statistik sampel. Ini termasuk ruang dari dokumen yang dihapus dan segmen kosong.

Metrik tingkat indeks

UnusedStorageSize(tingkat indeks)

• Lokasi - Perintah Database IndexStats

• Deskripsi — Memperkirakan ruang penyimpanan yang tidak digunakan dalam indeks berdasarkan statistik sampel. Ini termasuk ruang dari entri indeks usang dan segmen kosong.

• Rekomendasi — Gunakan reIndex perintah untuk membangun kembali indeks tanpa downtime dan merebut kembali ruang yang tidak digunakan. Lihat Mengelola Indeks untuk detail selengkapnya.

Contoh collStats keluaran

{
    "ns": "xid_consumption_test_db.xid_test_collection",
    "MVCCIdStats": {
        "MVCCIdScale": 0.03
    },
    "gcRuntimeStats": {
        "numRuns": 1,
        "historicalAvgRuntime": 3295,
        "historicalMaxRuntime": 3295,
        "lastRuntime": 3295,
        "lastRuntimeStart": ISODate("2025-06-24T08:47:14Z")
    },
    "collScans": 14,
    "count": 30000000,
    "size": 1320000000,
    "avgObjSize": 44,
    "storageSize": 6461497344,
    "capped": false,
    "nindexes": 2,
    "totalIndexSize": 9649553408,
    "indexSizes": {
        "_id_": 1910661120,
        "c_1": 7738892288
    },
    "unusedStorageSize": {
        "unusedBytes": 4201881600,
        "unusedPercent": 65.05
    },
    "cacheStats": {
        "collBlksHit": 171659016,
        "collBlksRead": 754061,
        "collHitRatio": 99.5627,
        "idxBlksHit": 692563636,
        "idxBlksRead": 1177921,
        "idxHitRatio": 99.8303
    },
    "idxScans": 41823984,
    "opCounter": {
        "numDocsIns": 0,
        "numDocsUpd": 20911992,
        "numDocsDel": 0
    },
    "lastReset": "2025-06-24 05:57:08.219711+00",
    "ok": 1,
    "operationTime": Timestamp(1750968826, 1)
}

Pertanyaan umum

Topik

• Bagaimana cara mengidentifikasi jika pengumpulan sampah tidak bekerja secara efisien?

• Apakah pengumpulan sampah mempengaruhi kinerja database saya?

• Bisakah saya memicu pengumpulan sampah secara manual?

• Alarm apa yang harus saya tetapkan sebagai praktik terbaik operasional?

• Apa yang harus saya lakukan jika saya AvailableMVCCId jatuh di bawah 1,3 miliar?

Bagaimana cara mengidentifikasi jika pengumpulan sampah tidak bekerja secara efisien?

Pantau tanda-tanda peringatan ini yang menunjukkan pengumpulan sampah yang tidak efisien:

• Collection bloat yang berlebihan — UnusedStorageSize Metrik yang terus meningkat selama penulisan berat atau penghapusan massal, terutama dengan indeks besar

• Latensi kueri terdegradasi — Peningkatan latensi kueri karena akumulasi dokumen mati

• Durasi GC yang diperpanjang — Operasi pengumpulan sampah memakan waktu lebih lama dari rata-rata historis di GCRuntimeStats

• Pemrosesan GC yang ditinggikan - Tinggi LongestRunningGCProcess menunjukkan bahwa pengumpul sampah tidak dapat memenuhi permintaan sistem

Apakah pengumpulan sampah mempengaruhi kinerja database saya?

Dalam kondisi normal, pengumpulan sampah memiliki dampak kinerja minimal. Namun, ketika pengumpulan sampah tertinggal, Anda mungkin mengalami:

• peningkatan biaya penyimpanan dari akumulasi dokumen mati.

• kinerja kueri lebih lambat karena entri indeks usang.

• mode read-only sementara jika MVCC habis IDs .

• penggunaan sumber daya yang lebih tinggi selama proses pengumpulan intensif, terutama pada instance yang lebih kecil.

Bisakah saya memicu pengumpulan sampah secara manual?

Tidak, pengumpulan sampah di Amazon DocumentDB tidak dapat dipicu secara manual. Sistem mengelola pengumpulan sampah secara otomatis sebagai bagian dari operasi pemeliharaan internalnya.

Alarm apa yang harus saya tetapkan sebagai praktik terbaik operasional?

Sebaiknya siapkan pemantauan di tingkat cluster dan koleksi untuk memastikan kinerja optimal sistem Amazon DocumentDB Anda.

Untuk pemantauan tingkat cluster

Mulailah dengan membuat CloudWatch alarm untuk AvailableMVCCId metrik dengan ambang 1,3 miliar. Ini memberi Anda waktu yang cukup untuk mengambil tindakan sebelum metrik mencapai nol, di mana klaster Anda akan memasuki mode hanya-baca. Ingatlah bahwa metrik ini dapat berfluktuasi berdasarkan pola penggunaan spesifik Anda. Beberapa pelanggan melihatnya turun di bawah 1,3 miliar dan kemudian pulih di atas 1,5 miliar karena pengumpulan sampah menyelesaikan pekerjaannya.

Penting juga untuk memantau LongestRunningGCProcess metrik melalui CloudWatch. Metrik ini, bersama denganGCRuntimeStats, membantu Anda memahami seberapa efisien kinerja pengumpulan sampah di seluruh sistem Anda.

Untuk pemantauan tingkat pengumpulan

Fokus pada dua metrik utama. Pertama, kami sarankan untuk menonton MvccIdAgeScale nilai untuk setiap koleksi. Nilai yang meningkat menunjukkan bahwa MVCC IDs menua dan mungkin perlu perhatian. Kedua, monitor GCRuntimeStats untuk mengidentifikasi proses pengumpulan sampah yang memakan waktu sangat lama atau diperpanjang selama beberapa hari. Koleksi dengan operasi menulis yang sering membutuhkan perhatian ekstra, karena mereka menghasilkan lebih banyak pekerjaan untuk pengumpul sampah. Sebaiknya periksa metrik ini lebih sering untuk koleksi dengan aktivitas menulis berat untuk memastikan pengumpulan sampah mengikuti beban kerja Anda.

Perhatikan bahwa rekomendasi pemantauan ini berfungsi sebagai titik awal. Saat Anda menjadi lebih akrab dengan perilaku sistem Anda, Anda mungkin ingin menyesuaikan ambang batas ini agar lebih sesuai dengan pola dan persyaratan penggunaan spesifik Anda.

Apa yang harus saya lakukan jika saya AvailableMVCCId jatuh di bawah 1,3 miliar?

Jika AvailableMVCCId metrik Anda turun di bawah 1,3 miliar, sebaiknya segera ambil tindakan untuk mencegah klaster Anda memasuki mode hanya-baca. Kami sarankan terlebih dahulu meningkatkan ukuran instans Anda untuk menyediakan sumber daya komputasi yang lebih banyak kepada pengumpul sampah. Ini memungkinkan aplikasi Anda untuk melanjutkan operasi normal sambil memberi pengumpul sampah daya tambahan yang dibutuhkan untuk mengejar ketinggalan.

Jika penskalaan saja tidak memperbaiki situasi, sebaiknya pertimbangkan pengurangan operasi penulisan Anda. Gunakan MvccIdAgeScale metrik untuk mengidentifikasi koleksi spesifik mana yang berisi MVCC lama IDs yang perlu diperhatikan. Setelah Anda mengidentifikasi koleksi ini, Anda mungkin perlu untuk sementara mengurangi operasi penulisan untuk memungkinkan pengumpulan sampah untuk mengejar ketinggalan. Selama periode pemulihan, kami sarankan untuk memantau AvailableMVCCId metrik dengan cermat untuk memastikan tindakan Anda memiliki efek yang diinginkan. Cluster Anda dianggap sehat setelah AvailableMVCCId nilainya kembali ke 1,5 miliar atau lebih tinggi.

Ingatlah bahwa langkah-langkah ini adalah tindakan pencegahan untuk membantu sistem Anda pulih sebelum mencapai keadaan kritis. Semakin cepat Anda mengambil tindakan setelah melihat penurunan metrik di bawah 1,3 miliar, semakin besar kemungkinan Anda untuk menghindari dampak apa pun pada operasi penulisan Anda.