Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Pemecahan Masalah Amazon DocumentDB
Bagian berikut ini menyediakan informasi tentang cara untuk memecahkan masalah yang mungkin Anda alami ketika menggunakan Amazon DocumentDB (dengan kompatibilitas MongoDB).
**Topics**
+ [Masalah koneksi](troubleshooting.connecting.md)
+ [Indeks](troubleshooting.index-creation.md)
+ [Kinerja dan pemanfaatan sumber daya](user_diagnostics.md)
+ [Pengumpulan sampah](garbage-collection.md)
# Memecahkan masalah koneksi
Mengalami masalah saat menghubungkan? Berikut ini adalah beberapa skenario umum dan cara untuk mengatasinya.
**Topik**
+ [Tidak dapat terhubung ke titik akhir Amazon DocumentDB](#troubleshooting-connecting)
+ [Menguji koneksi ke instans Amazon DocumentDB](#troubleshooting.testing-connection)
+ [Menghubungkan ke titik akhir yang tidak valid](#troubleshooting.invalid-endpoint)
+ [Konfigurasi driver yang memengaruhi jumlah koneksi](#troubleshooting.driver.config)
## Tidak dapat terhubung ke titik akhir Amazon DocumentDB
Ketika Anda mencoba untuk menyambungkan ke Amazon DocumentDB, berikut ini adalah salah satu pesan kesalahan yang paling umum yang mungkin Anda terima.
```
connecting to: mongodb://docdb-2018-11-08-21-47-27.cluster-ccuszbx3pn5e.us-east-
1.docdb.amazonaws.com:27017/
2018-11-14T14:33:46.451-0800 W NETWORK [thread1] Failed to connect to
172.31.91.193:27017 after 5000ms milliseconds, giving up.
2018-11-14T14:33:46.452-0800 E QUERY [thread1] Error: couldn't connect to server
docdb-2018-11-08-21-47-27.cluster-ccuszbx3pn5e.us-east-1.docdb.amazonaws.com:27017,
connection attempt failed :
connect@src/mongo/shell/mongo.js:237:13
@(connect):1:6
exception: connect failed
```
Arti pesan kesalahan ini biasanya adalah bahwa klien Anda (mongo shell dalam contoh ini) tidak dapat mengakses titik akhir Amazon DocumentDB. Hal ini dapat terjadi karena beberapa alasan:
**Topics**
+ [Menghubungkan dari titik akhir publik](#troubleshooting.cannot-connect.public-endpoints)
+ [Koneksi lintas wilayah](#troubleshooting.cannot-connect.different-regions)
+ [Menghubungkan dari Amazon yang berbeda VPCs](#troubleshooting.cannot-connect.different-vpcs)
+ [Grup keamanan memblokir koneksi masuk](#troubleshooting.cannot-connect.inbound-not-allowed)
+ [Driver Java Mongo membaca masalah preferensi](#troubleshooting-cannot-connect-java-mongo-issue)
### Menghubungkan dari titik akhir publik
**Anda mencoba terhubung ke cluster Amazon DocumentDB langsung dari laptop atau mesin pengembangan lokal Anda.**
Mencoba untuk menghubungkan ke klaster Amazon DocumentDB langsung dari titik akhir publik, seperti laptop Anda atau mesin pengembangan lokal, akan gagal. Amazon DocumentDB adalah virtual private cloud (VPC)-satu-satunya dan saat ini tidak mendukung titik akhir publik. Dengan demikian, Anda tidak dapat menghubugkan secara langsung ke klaster Amazon DocumentDB Anda dari laptop Anda atau lingkungan pengembangan lokal di luar VPC Anda.
Untuk menghubungkan ke klaster Amazon DocumentDB dari luar Amazon VPC, Anda dapat menggunakan terowongan SSH. Untuk informasi selengkapnya, lihat [Menghubungkan ke cluster Amazon DocumentDB dari luar Amazon VPC](connect-from-outside-a-vpc.md). Selain itu, jika lingkungan pengembangan Anda adalah dalam Amazon VPC yang berbeda, Anda juga dapat menggunakan Peering VPC dan menghubungkan ke klaster Amazon DocumentDB Anda dari Amazon VPC lainnya di wilayah yang sama atau wilayah yang berbeda.
### Koneksi lintas wilayah
**Anda mencoba terhubung ke cluster Amazon DocumentDB di wilayah lain.**
Jika Anda mencoba untuk menghubungkan ke klaster Amazon DocumentDB dari instans Amazon EC2 di Wilayah selain Wilayah klaster ini—sebagai contoh, mencoba untuk menghubungkan ke klaster di Wilayah US East (N. Virginia) (us-east-1) dari Wilayah US West (Oregon) (us-west-2)—koneksi akan gagal.
Untuk memverifikasi Wilayah klaster Amazon DocumentDB Anda, jalankan perintah berikut ini. Wilayah ini berada di titik akhir.
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].Endpoint'
```
Keluaran dari operasi ini terlihat seperti berikut ini.
```
[
"sample-cluster.node.us-east-1.docdb.amazonaws.com"
]
```
Untuk memverifikasi Wilayah instans EC2 Anda, jalankan perintah berikut ini.
```
aws ec2 describe-instances \
--query 'Reservations[*].Instances[*].Placement.AvailabilityZone'
```
Output dari operasi ini akan terlihat seperti berikut.
```
[
[
"us-east-1a"
]
]
```
### Menghubungkan dari Amazon yang berbeda VPCs
**Anda mencoba terhubung ke cluster Amazon DocumentDB dari VPC yang berbeda dari VPC Amazon yang digunakan cluster Anda.**
Jika cluster Amazon DocumentDB dan instans Amazon EC2 Anda sama, tetapi tidak di VPC Amazon Wilayah AWS yang sama, Anda tidak dapat terhubung langsung ke cluster Amazon DocumentDB Anda kecuali VPC Peering diaktifkan di antara dua Amazon. VPCs
Untuk memverifikasi Amazon VPC dari instans Amazon DocumentDB Anda, jalankan perintah berikut ini.
```
aws docdb describe-db-instances \
--db-instance-identifier sample-instance \
--query 'DBInstances[*].DBSubnetGroup.VpcId'
```
Untuk memverifikasi Amazon VPC dari instans Amazon EC2 Anda, jalankan perintah berikut ini.
```
aws ec2 describe-instances \
--query 'Reservations[*].Instances[*].VpcId'
```
### Grup keamanan memblokir koneksi masuk
**Anda mencoba terhubung ke klaster Amazon DocumentDB, dan grup keamanan klaster tidak mengizinkan koneksi masuk pada port cluster (port default: 27017).**
Anggap bahwa klaster Amazon DocumentDB Anda dan instans Amazon EC2 keduanya di Wilayah dan Amazon VPC yang sama dan menggunakan grup keamanan Amazon VPC yang sama. Jika Anda tidak dapat menghubungkan ke klaster Amazon DocumentDB Anda, kemungkinan penyebabnya adalah bahwa grup keamanan Anda (yaitu, firewall) untuk klaster Anda tidak mengizinkan koneksi inbound pada port yang Anda pilih untuk klaster Amazon DocumentDB Anda (port default adalah 27017).
Untuk memverifikasi port untuk klaster Amazon DocumentDB Anda , jalankan perintah berikut ini.
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].[DBClusterIdentifier,Port]'
```
Untuk mendapatkan grup keamanan Amazon DocumentDB Anda untuk klaster Anda, jalankan perintah berikut ini.
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].[VpcSecurityGroups[*],VpcSecurityGroupId]'
```
Untuk memeriksa aturan inbound untuk grup keamanan Anda, lihat topik berikut ini dalam dokumentasi Amazon EC2:
+ [Otorisasi Lalu Lintas Masuk untuk Instans Linux Anda](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/authorizing-access-to-an-instance.html)
+ [Mengotorisasi Lalu Lintas Masuk untuk Instans Windows Anda](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/authorizing-access-to-an-instance.html)
### Driver Java Mongo membaca masalah preferensi
**Preferensi baca klien tidak dihormati dan beberapa klien tidak dapat menulis ke Amazon DocumentDB setelah failover kecuali mereka reboot.**
Masalah ini, pertama kali ditemukan di Java Mongo Driver 3.7.x, terjadi ketika klien membuat koneksi ke Amazon DocumentDB menggunakan `MongoClientSettings` dan, khususnya, saat merantai metode. `applyToClusterSettings` Pengaturan MongoClient Cluster dapat didefinisikan menggunakan beberapa metode yang berbeda, seperti`hosts()`,`requiredReplicaSetName()`, dan`mode()`.
Ketika klien hanya menentukan satu host dalam `hosts()` metode, mode diatur ke `ClusterConnectionMode.SINGLE` bukan `ClusterConnectionMode.MULTIPLE` Ini menyebabkan klien mengabaikan preferensi baca dan hanya terhubung ke server yang dikonfigurasi. `hosts()` Jadi, bahkan jika pengaturan klien diinisialisasi seperti di bawah ini, semua pembacaan akan tetap pergi ke primer, bukan yang sekunder.
```
final ServerAddress serverAddress0 = new ServerAddress("cluster-endpoint", 27317));
final MongoCredential credential = MongoCredential.createCredential("xxx",
"admin", "xxxx".toCharArray());
final MongoClientSettings settings = MongoClientSettings.builder()
.credential(credential)
.readPreference(ReadPreference.secondaryPreferred())
.retryWrites(false)
.applyToSslSettings(builder -> builder
.enabled(false))
.applyToClusterSettings(builder -> builder.hosts(
Arrays.asList(serverAddress0
))
.requiredReplicaSetName("rs0"))
.build();
MongoClient mongoClient = MongoClients.create(settings);
```
**Kasus failover**
Menggunakan pengaturan koneksi klien di atas, jika ada failover dan pembaruan catatan DNS yang tertunda untuk titik akhir penulis cluster, klien masih akan mencoba mengeluarkan penulisan ke penulis lama (sekarang pembaca setelah failover). Ini menghasilkan kesalahan sisi server (bukan primer) yang tidak ditangani dengan tepat oleh driver Java (ini masih dalam penyelidikan). Dengan demikian, klien dapat dibiarkan dalam keadaan buruk sampai server aplikasi di-boot ulang, misalnya.
Ada dua solusi untuk ini:
+ Klien yang terhubung ke Amazon DocumentDB melalui string koneksi tidak akan mengalami masalah ini, `ClusterConnectionMode` karena akan disetel `MULTIPLE` ke saat menyetel preferensi baca.
```
MongoClientURI mongoClientURI = new MongoClientURI("mongodb://usr:pass:cluster-endpoint:27317/test?ssl=false&replicaSet=rs0&readpreference=secondaryPreferred");
MongoClient mongoClient = MongoClients.create(mongoClientURI.getURI());
```
Atau menggunakan `MongoClientSettings` pembangun dengan `applyConnectionString` metode ini.
```
final MongoClientSettings settings = MongoClientSettings.builder()
.credential(credential)
.applyConnectionString(new ConnectionString("usr:pass:cluster-endpoint:27317/test?ssl=false&replicaSet=rs0&readpreference=secondaryPreferred"))
.retryWrites(false)
.applyToSslSettings(builder → builder
.enabled(false))
.build();
MongoClient mongoClient = MongoClients.create(settings);
```
+ Secara eksplisit diatur `ClusterConnectionMode` ke. `MULTIPLE` Ini hanya diperlukan saat menggunakan `applyToClusterSettings` dan`hosts().size() == 1`.
```
final ServerAddress serverAddress0 = new ServerAddress("cluster-endpoint", 27317));
final MongoCredential credential = MongoCredential.createCredential("xxx","admin", "xxxx".toCharArray());
final MongoClientSettings settings = MongoClientSettings.builder()
.credential(credential)
.readPreference(ReadPreference.secondaryPreferred())
.retryWrites(false)
.applyToSslSettings(builder → builder
.enabled(false))
.applyToClusterSettings(builder → builder
.hosts(Arrays.asList(serverAddress0))
.requiredReplicaSetName("rs0"))
.mode(ClusterConnectionMode.MULTIPLE))
.build();
MongoClient mongoClient = MongoClients.create(settings);
```
## Menguji koneksi ke instans Amazon DocumentDB
Anda dapat menguji koneksi ke klaster menggunakan alat Linux atau Windows umum.
Dari terminal Linux atau Unix, Anda dapat menguji koneksi dengan memasukkan hal berikut ini (ganti `cluster-endpoint` dengan titik akhir, dan ganti `port` dengan port instans Anda):
```
nc -zv cluster-endpoint port
```
Berikut ini adalah contoh operasi sampel dan nilai balik:
```
nc -zv docdbTest.d4c7nm7stsfc0.us-west-2.docdb.amazonaws.com 27017
Connection to docdbTest.d4c7nm7stsfc0.us-west-2.docdb.amazonaws.com 27017 port [tcp/*] succeeded!
```
## Menghubungkan ke titik akhir yang tidak valid
Ketika menghubungkan ke klaster Amazon DocumentDB dan Anda menggunakan titik akhir klaster yang tidak valid, muncul kesalahan yang mirip dengan berikut ini.
```
mongo --ssl \
--host sample-cluster.node.us-east-1.docdb.amazonaws.com:27017 \
--sslCAFile global-bundle.pem \
--username \
--password
```
Keluaran terlihat seperti ini:
```
MongoDB shell version v3.6
connecting to: mongodb://sample-cluster.node.us-east-1.docdb.amazonaws.com:27017/
2018-11-14T17:21:18.516-0800 I NETWORK [thread1] getaddrinfo("sample-cluster.node.us-east-1.docdb.amazonaws.com") failed:
nodename nor servname provided, or not known 2018-11-14T17:21:18.537-0800 E QUERY [thread1] Error: couldn't initialize
connection to host sample-cluster.node.us-east-1.docdb.amazonaws.com, address is invalid :
connect@src/mongo/shell/mongo.js:237:13@(connect):1:6
exception: connect failed
```
Untuk mendapatkan titik akhir yang valid untuk klaster, jalankan perintah berikut ini:
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].[Endpoint,Port]'
```
Untuk mendapatkan titik akhir yang valid untuk instans, jalankan perintah berikut ini:
```
aws docdb describe-db-instances \
--db-instance-identifier sample-instance \
--query 'DBInstances[*].[Endpoint.Address,Endpoint.Port]'
```
Untuk informasi selengkapnya, lihat [Memahami titik akhir Amazon DocumentDB](endpoints.md).
## Konfigurasi driver yang memengaruhi jumlah koneksi
Saat menggunakan driver klien untuk terhubung ke cluster Amazon DocumentDB, penting untuk mempertimbangkan `maxPoolSize` parameter konfigurasi. `maxPoolSize`Pengaturan menentukan jumlah maksimum koneksi yang akan dipertahankan oleh driver klien di kumpulan koneksinya.
# Pemecahan masalah indeks
Topik berikut ini membahas apa yang harus dilakukan jika indeks atau pembuatan indeks latar belakang gagal.
**Topics**
+ [Pembuatan indeks gagal](#troubleshooting.index-build-fails)
+ [Indeks latar belakang membangun masalah latensi dan gagal](#troubleshooting.background-index-build-fails)
+ [Indeks basis data kembung](#troubleshooting-database-bloat)
## Pembuatan indeks gagal
Amazon DocumentDB menggunakan penyimpanan lokal pada instans sebagai bagian dari proses pembuatan indeks. Anda dapat memantau penggunaan disk ini menggunakan **FreeLocalStorage** CloudWatch metrik (`CloudWatch -> Metrics -> DocDB -> Instance Metrics`). Ketika pembuatan indeks mengonsumsi semua disk lokal dan gagal, Anda akan menerima kesalahan. Ketika memigrasi data ke Amazon DocumentDB, kami mendorong Anda untuk membuat indeks terlebih dahulu dan kemudian memasukkan data. Untuk informasi selengkapnya tentang strategi migrasi dan membuat indeks, lihat [Migrasi ke Amazon DocumentDB](docdb-migration.md) dalam dokumentasi Amazon DocumentDB dan blog: [Bermigrasi dari MongoDB ke Amazon DocumentDB menggunakan metode offline](https://aws.amazon.com/blogs/database/migrate-from-mongodb-to-amazon-documentdb-using-the-offline-method/).
Ketika membuat indeks pada klaster yang ada, jika pembuatan indeks membutuhkan waktu lebih lama dari yang diharapkan atau gagal, kami sarankan Anda menskalakan ke atas instans untuk membuat indeks kemudian, setelah indeks dibuat, menskalakan kembali ke bawah. Amazon DocumentDB memungkinkan Anda menskalakan ukuran instans dengan cepat dalam hitungan menit menggunakan Konsol Manajemen AWS atau file. AWS CLI Untuk informasi selengkapnya, lihat [Mengelola kelas instance](db-instance-classes.md). Dengan harga instans per detik, Anda hanya membayar untuk sumber daya yang Anda gunakan hingga hitungan detik.
## Indeks latar belakang membangun masalah latensi dan gagal
Indeks latar belakang yang dibangun di Amazon DocumentDB tidak mulai hingga semua kueri pada instans primer yang dimulai sebelum pembuatan indeks dijalankan secara lengkap saat dimulai. Jika terdapat kueri yang berjalan lama, pembuatan indeks latar belakang akan memblokir hingga kueri selesai dan dengan demikian dapat membutuhkan waktu lebih lama dari yang diharapkan untuk menyelesaikan. Hal ini berlaku bahkan jika koleksi kosong.
Pembuatan indeks latar depan tidak menunjukkan perilaku pemblokiran yang sama. Sebaliknya, pembuatan indeks latar depan mengambil kunci eksklusif pada koleksi hingga pembuatan indeks selesai. Dengan demikian, untuk membuat indeks pada koleksi kosong dan untuk menghindari pemblokiran pada setiap kueri yang berjalan lama, kami sarankan menggunakan pembuatan indeks latar depan.
**catatan**
Amazon DocumentDB hanya mengizinkan satu pembuatan indeks latar belakang terjadi pada koleksi pada waktu tertentu. Jika operasi DDL (Data Definition Language) seperti `createIndex()` atau `dropIndex()` terjadi pada koleksi yang sama selama pembuatan indeks latar belakang, pembuatan indeks latar belakang akan gagal.
## Indeks basis data kembung
Amazon DocumentDB menggunakan Multi-Version Concurrency Concurrency Control (MVCC) untuk mengelola transaksi bersamaan. Ketika dokumen dihapus atau diperbarui, versi sebelumnya tetap dalam koleksi dan indeks sebagai versi “mati”. Proses pengumpulan sampah secara otomatis merebut kembali ruang dari versi mati ini untuk operasi masa depan.
Index bloat terjadi ketika indeks koleksi menjadi lebih besar karena akumulasi entri indeks mati atau usang atau fragmentasi dalam halaman. Persentase yang dilaporkan mewakili jumlah ruang indeks yang dapat digunakan oleh entri indeks future. Bloat ini menghabiskan ruang di cache buffer dan penyimpanan. Jika Anda ingin menghapus kembung, Anda perlu membangun kembali indeks.
**Example Contoh**
Jalankan perintah berikut untuk menentukan penyimpanan yang tidak digunakan untuk indeks Anda:
```
db.coll.aggregate({$indexStats:{}});
```
Hasilnya terlihat mirip dengan ini:
```
{
"name" : "_id_",
"key" : {
"_id" : 1
},
"host" : "devbox-test.localhost.a2z.com:27317",
"size" : NumberLong(827392),
"accesses" : {
"ops" : NumberLong(40000),
"docsRead" : NumberLong(46049),
"since" : ISODate("2025-04-03T21:44:51.251Z")
},
"cacheStats" : {
"blksRead" : NumberLong(264),
"blksHit" : NumberLong(140190),
"hitRatio" : 99.8121
},
"unusedStorageSize" : {
"unusedSizeBytes" : 409600,
"unusedSizePercent" : 49.51
}
}
```
Anda dapat membangun kembali indeks tanpa downtime menggunakan `reIndex` perintah, yang memerlukan pemindaian seluruh koleksi. Lihat [Pemeliharaan indeks menggunakan `reIndex`](managing-indexes.md#reIndex).
# Pemecahan masalah kinerja dan pemanfaatan sumber daya
Bagian ini menyediakan pertanyaan dan solusi untuk masalah diagnostik umum dalam deployment Amazon DocumentDB. Contoh disediakan menggunakan *mongo shell* dan dicakupkan ke instans individu. Untuk menemukan titik akhir instans, lihat [Memahami titik akhir Amazon DocumentDB](endpoints.md).
**Topics**
+ [Bagaimana cara menentukan jumlah operasi penyisipan, pembaruan, dan penghapusan yang dilakukan pada koleksi saya melalui Mongo API?](#user-diag-performed-operations)
+ [Bagaimana cara menganalisis kinerja cache?](#user-diag-cache-perf)
+ [Bagaimana cara menemukan dan menghentikan kueri yang berjalan lama atau diblokir?](#user_diagnostics-query_terminating)
+ [Bagaimana saya bisa melihat rencana kueri dan mengoptimalkan kueri?](#user_diagnostics-query_plan)
+ [Bagaimana saya bisa melihat rencana kueri dalam cluster elastis?](#user-diagnostics-ec-query-plan)
+ [Bagaimana cara saya mencantumkan semua operasi yang berjalan pada sebuah instance?](#user_diagnostics-list_queries)
+ [Bagaimana saya tahu kapan kueri membuat kemajuan?](#user_diagnostics-query_progressing)
+ [Bagaimana cara menentukan mengapa sistem tiba-tiba berjalan lambat?](#user_diagnostics-speed_change)
+ [Bagaimana cara menentukan penyebab pemanfaatan CPU yang tinggi pada satu atau lebih instance cluster?](#user_diagnostics-cpu_utilization)
+ [Bagaimana cara menentukan kursor terbuka pada sebuah instance?](#user_diagnostics-open_cursors)
+ [Bagaimana cara menentukan versi mesin Amazon DocumentDB saat ini?](#user_diagnostics-engine_version)
+ [Bagaimana cara menganalisis penggunaan indeks dan mengidentifikasi indeks yang tidak digunakan?](#user-diag-index-usage)
+ [Bagaimana cara mengidentifikasi indeks yang hilang?](#user_diagnostics-identify_missing_indexes)
+ [Bagaimana cara menentukan pengumpulan database bloat?](#performance-collection-bloat)
+ [Ringkasan pertanyaan yang berguna](#user_diagnostics-useful_queries)
## Bagaimana cara menentukan jumlah operasi penyisipan, pembaruan, dan penghapusan yang dilakukan pada koleksi saya melalui Mongo API?
Untuk melihat jumlah operasi penyisipan, pembaruan, dan penghapusan yang dilakukan pada koleksi tertentu, jalankan perintah berikut pada koleksi tersebut:
```
db.collection.stats()
```
Output dari perintah ini menjelaskan hal berikut di bawah `opCounters` bidangnya:
+ **numDocsIns**- Jumlah dokumen yang dimasukkan ke dalam koleksi ini. Ini termasuk dokumen yang dimasukkan menggunakan `insertMany` perintah `insert` dan, serta dokumen yang dimasukkan oleh upsert.
+ **numDocsUpd**- Jumlah pembaruan dokumen dalam koleksi ini. Ini termasuk dokumen yang diperbarui menggunakan `findAndModify` perintah `update` dan.
+ **numDocsDel**- Jumlah dokumen yang dihapus dari koleksi ini. Ini termasuk dokumen yang dihapus menggunakan`deleteOne`,`deleteMany`,`remove`, dan `findAndModify` perintah.
+ **LastReset** - Waktu penghitung ini telah diatur ulang terakhir. Statistik yang disediakan oleh perintah ini diatur ulang saat starting/stopping cluster atau penskalaan up/down instance.
Contoh output dari menjalankan `db.collection.stats()` ditunjukkan di bawah ini.
```
{
"ns" : "db.test",
"count" : ...,
"size" : ...,
"avgObjSize" : ...,
"storageSize" : ...,
"capped" : false,
"nindexes" : ...,
"totalIndexSize" : ...,
"indexSizes" : {
"_id_" : ...,
"x_1" : ...
},
"collScans" : ...,
"idxScans" : ...,
"opCounter" : {
"numDocsIns" : ...,
"numDocsUpd" : ...,
"numDocsDel" : ...
},
"cacheStats" : {
"collBlksHit" : ...,
"collBlksRead" : ..,
"collHitRatio" : ...,
"idxBlksHit" : ...,
"idxBlksRead" : ...,
"idxHitRatio" : ...
},
"lastReset" : "2022-09-02 19:41:40.471473+00",
"ok" : 1,
"operationTime" : Timestamp(1662159707, 1)
}
```
Perintah statistik ini harus digunakan saat melihat penghitung khusus koleksi untuk menyisipkan, memperbarui, dan menghapus operasi melalui Mongo API. Cara lain untuk melihat penghitung operasi khusus koleksi adalah dengan mengaktifkan audit DHTML. Jumlah operasi penyisipan, perbarui, dan hapus pada semua koleksi selama interval waktu satu menit dapat dilihat di[Memantau Amazon DocumentDB dengan CloudWatch](cloud_watch.md).
## Bagaimana cara menganalisis kinerja cache?
Menganalisis kinerja cache dapat memberikan wawasan tentang efisiensi pengambilan data dan kinerja sistem, dan didasarkan pada berapa banyak data yang dibaca dari disk versus cache. Kami menyediakan statistik cache tentang jumlah klik cache (data yang dibaca dari cache) dan cache yang salah (data yang tidak ditemukan di cache dan dibaca dari disk) untuk memberikan wawasan tentang kinerja cache. Statistik cache untuk koleksi tertentu dapat ditemukan dengan menjalankan perintah berikut pada koleksi itu:
```
db.collection.stats()
```
Nilai-nilai di `cacheStats` bidang dalam output dari perintah ini menyediakan statistik cache untuk koleksi serta statistik cache total untuk indeks yang dibuat pada koleksi. Statistik ini tercantum di bawah ini:
+ **`collBlksHit`**- Jumlah blok yang dibaca dari cache selama operasi pada koleksi ini.
+ **`collBlksRead`**- Jumlah blok yang dibaca dari disk (cache meleset) selama operasi pada koleksi ini.
+ **`collHitRatio`**- Rasio hit cache untuk koleksi ini (`100 * [collBlksHit / (collBlksHit + collBlksRead)]`).
+ **`idxBlksHit`**- Jumlah blok yang dibaca dari cache untuk indeks apa pun yang dibuat pada koleksi ini.
+ **`idxBlksRead`**- Jumlah blok yang dibaca dari disk (cache meleset) untuk indeks apa pun yang dibuat pada koleksi ini.
+ **`idxHitRatio`**- Rasio hit cache untuk indeks yang dibuat pada koleksi ini (`100 * [idxBlksHit / (idxBlksHit + idxBlksRead)]`).
+ **`lastReset`**- Waktu statistik ini telah diatur ulang terakhir. Statistik yang disediakan oleh `db.collection.stats()` diatur ulang saat starting/stopping cluster atau penskalaan up/down instance.
Rincian `idxBlksRead` bidang `idxBlksHit` dan untuk setiap indeks juga dapat ditemukan menggunakan `indexStats` perintah. Statistik cache indeks tertentu dapat ditemukan dengan menjalankan perintah berikut:
```
db.collection.aggregate([{$indexStats:{}}]).pretty()
```
Untuk setiap indeks, statistik cache berikut dapat ditemukan di bawah `cacheStats` bidang:
+ **`blksHit`**- Jumlah blok yang dibaca dari cache untuk indeks ini.
+ **`blksRead`**- Jumlah blok yang dibaca dari disk untuk indeks ini.
+ **`blksHitRatio`**- Rasio hit cache dibulatkan ke empat tempat desimal, dihitung dengan. `100 * [blksHit / (blksHit + blksRead)]`
## Bagaimana cara menemukan dan menghentikan kueri yang berjalan lama atau diblokir?
Kueri pengguna dapat berjalan lambat karena rencana kueri suboptimal atau dapat diblokir akibat kontensi sumber daya.
Untuk menemukan kueri yang berjalan lama yang melambat akibat rencana kueri suboptimal, atau kueri yang diblokir akibat kontensi sumber daya, gunakan perintah `currentOp`. Anda dapat menyaring perintah untuk membantu mempersempit daftar kueri yang relevan untuk mengakhiri. Anda harus memiliki `opid` yang berkaitan dengan kueri yang berjalan lama untuk dapat mengakhiri kueri.
Kueri berikut ini menggunakan perintah `currentOp` untuk mendaftar semua kueri yang diblokir maupun yang berjalan selama lebih dari 10 detik.
```
db.adminCommand({
aggregate: 1,
pipeline: [
{$currentOp: {}},
{$match:
{$or: [
{secs_running: {$gt: 10}},
{WaitState: {$exists: true}}]}},
{$project: {_id:0, opid: 1, secs_running: 1}}],
cursor: {}
});
```
Selanjutnya, Anda dapat mempersempit kueri untuk menemukan `opid` dari kueri yang berjalan selama lebih dari 10 detik dan mengakhirinya.
**Untuk menemukan dan mengakhiri kueri yang berjalan selama lebih dari 10 detik**
1. Temukan `opid` kueri.
```
db.adminCommand({
aggregate: 1,
pipeline: [
{$currentOp: {}},
{$match:
{$or:
[{secs_running: {$gt: 10}},
{WaitState: {$exists: true}}]}}],
cursor: {}
});
```
Keluaran dari operasi ini terlihat seperti berikut ini (format JSON).
```
{
"waitedMS" : NumberLong(0),
"cursor" : {
"firstBatch" : [
{
"opid" : 24646,
"secs_running" : 12
}
],
"id" : NumberLong(0),
"ns" : "admin.$cmd"
},
"ok" : 1
}
```
1. Mengakhiri kueri menggunakan operasi `killOp`.
```
db.adminCommand({killOp: 1, op: 24646});
```
## Bagaimana saya bisa melihat rencana kueri dan mengoptimalkan kueri?
Jika kueri berjalan lambat, itu bisa karena eksekusi kueri memerlukan pemindaian penuh koleksi untuk memilih dokumen yang relevan. Kadang-kadang membuat indeks yang sesuai memungkinkan kueri untuk berjalan lebih cepat. Untuk mendeteksi skenario ini dan memutuskan bidang untuk membuat indeks, gunakan perintah `explain`.
**catatan**
Amazon DocumentDB mengemulasi MongoDB 3.6 API pada mesin basis data yang dibuat khusus yang memanfaatkan sistem penyimpanan yang didistribusikan, toleran terhadap kesalahan, dan penyembuhkan diri sendiri. Akibatnya, rencana kueri dan keluaran dari `explain()` mungkin berbeda antara Amazon DocumentDB dan MongoDB. Pelanggan yang ingin kontrol atas rencana kueri mereka dapat menggunakan operator `$hint` untuk memaksa pemilihan indeks yang diutamakan.
Jalankan kueri yang ingin Anda tingkatkan di bawah perintah `explain` sebagai berikut.
```
db.runCommand({explain: {}})
```
Berikut ini adalah operasi contoh.
```
db.runCommand({explain:{
aggregate: "sample-document",
pipeline: [{$match: {x: {$eq: 1}}}],
cursor: {batchSize: 1}}
});
```
Keluaran dari operasi ini terlihat seperti berikut ini (format JSON).
```
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "db.test",
"winningPlan" : {
"stage" : "COLLSCAN"
}
},
"serverInfo" : {
"host" : "...",
"port" : ...,
"version" : "..."
},
"ok" : 1
}
```
Keluaran sebelumnya menunjukkan bahwa tahap `$match` membutuhkan pemindaian seluruh koleksi dan memeriksa apakah bidang `"x"` di setiap dokumen adalah sama dengan 1. Jika ada banyak dokumen dalam koleksi, pemindaian koleksi (dan karena itu performa kueri keseluruhan) sangat lambat. Dengan demikian adanya `"COLLSCAN"` dalam keluaran dari perintah `explain` menunjukkan bahwa performa kueri dapat ditingkatkan dengan membuat indeks yang sesuai.
Dalam contoh ini, kueri memeriksa apakah bidang `"x"` sama dengan 1 di semua dokumen. Jadi embuat indeks di bidang `"x"` memungkinkan kueri untuk menghindari pemindaian koleksi lengkap dan menggunakan indeks untuk mengembalikan dokumen yang relevan dengan lebih cepat.
Setelah membuat indeks pada bidang `"x"`, keluaran `explain` adalah sebagai berikut.
```
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "db.test",
"winningPlan" : {
"stage" : "IXSCAN",
"indexName" : "x_1",
"direction" : "forward"
}
},
"serverInfo" : {
"host" : "...",
"port" : ...,
"version" : "..."
},
"ok" : 1
}
```
Membuat indeks pada bidang `"x"` mengaktifkan tahap `$match` untuk menggunakan pemindaian indeks untuk mengurangi jumlah dokumen diana predikat `"x = 1"` harus dievaluasi.
Untuk koleksi kecil, prosesor kueri Amazon DocumentDB dapat memilih untuk tidak menggunakan indeks jika keuntungan performa diabaikan.
## Bagaimana saya bisa melihat rencana kueri dalam cluster elastis?
Untuk memeriksa rencana kueri dalam cluster elastis, gunakan `explain` perintah. Berikut ini adalah contoh `explain` operasi pada query find yang menargetkan koleksi sharded:
```
db.runCommand(
{
explain: { find: "cities", filter: {"name": "Seoul"}}
}
)
```
**catatan**
Amazon DocumentDB mengemulasi MongoDB pada mesin database yang dibuat khusus. Akibatnya, rencana kueri dan keluaran dari `explain()` mungkin berbeda antara Amazon DocumentDB dan MongoDB. Anda dapat mengontrol rencana kueri dengan menggunakan `$hint` operator untuk menerapkan pemilihan indeks pilihan.
Output dari operasi ini mungkin terlihat seperti berikut (format JSON):
```
{
"queryPlanner" : {
"elasticPlannerVersion" : 1,
"winningPlan" : {
"stage" : "SINGLE_SHARD",
"shards" : [
{
"plannerVersion" : 1,
"namespace" : "population.cities",
"winningPlan" : {
"stage" : "SHARD_MERGE",
"shards" : [
{
"shardName" : "f2cf5cfd-fe9c-40ca-b4e5-298ca0d11111",
"plannerVersion" : 1,
"namespace" : "population.cities",
"winningPlan" : {
"stage" : "PARTITION_MERGE",
"inputStages" : [
{
"stage" : "COLLSCAN",
"partitionCount" : 21
}
]
}
},
{
"shardName" : "8f3f80e2-f96c-446e-8e9d-aab8c7f22222",
"plannerVersion" : 1,
"namespace" : "population.cities",
"winningPlan" : {
"stage" : "PARTITION_MERGE",
"inputStages" : [
{
"stage" : "COLLSCAN",
"partitionCount" : 21
}
]
}
},
{
"shardName" : "32c5a06f-1b2b-4af1-8849-d7c4a033333",
"plannerVersion" : 1,
"namespace" : "population.cities",
"winningPlan" : {
"stage" : "PARTITION_MERGE",
"inputStages" : [
{
"stage" : "COLLSCAN",
"partitionCount" : 22
}
]
}
}
]
},
"shardName" : "32c5a06f-1b2b-4af1-8849-d7c4a0f3fb58"
}
]
}
},
"serverInfo" : {
"host" : "example-4788267630.us-east-1.docdb-elastic.amazonaws.com:27017",
"version" : "5.0.0"
},
"ok" : 1,
"operationTime" : Timestamp(1695097923, 1)
}
```
Output sebelumnya menunjukkan rencana kueri untuk `find` kueri pada cluster tiga pecahan. Setiap pecahan memiliki beberapa partisi data yang dapat memiliki tahapan input yang berbeda. Dalam contoh ini, “COLLSCAN “(pemindaian koleksi) dijalankan pada semua partisi sebelum hasilnya digabungkan pada tahap” PARTITION\$1MERGE “dalam setiap pecahan. Hasil di seluruh pecahan kemudian digabungkan bersama pada tahap” SHARD\$1MERGE “sebelum dikirim kembali ke klien.
## Bagaimana cara saya mencantumkan semua operasi yang berjalan pada sebuah instance?
Sebagai pengguna atau pengguna utama, Anda sering ingin mencantumkan semua operasi saat ini yang berjalan pada sebuah instance untuk tujuan diagnostik dan pemecahan masalah. (Untuk informasi tentang mengelola pengguna, lihat [Mengelola pengguna Amazon DocumentDB](security.managing-users.md).)
Dengan `mongo` shell, Anda dapat menggunakan kueri berikut ini untuk mendaftar semua operasi yang berjalan pada instans Amazon DocumentDB.
```
db.adminCommand({currentOp: 1, $all: 1});
```
Kueri mengembalikan daftar lengkap dari semua kueri pengguna dan tugas sistem internal yang saat ini beroperasi pada instans.
Keluaran dari operasi ini terlihat seperti berikut ini (format JSON).
```
{
"inprog" : [
{
"desc" : "INTERNAL"
},
{
"desc" : "TTLMonitor",
"active" : false
},
{
"client" : ...,
"desc" : "Conn",
"active" : true,
"killPending" : false,
"opid" : 195,
"ns" : "admin.$cmd",
"command" : {
"currentOp" : 1,
"$all" : 1
},
"op" : "command",
"$db" : "admin",
"secs_running" : 0,
"microsecs_running" : NumberLong(68),
"clientMetaData" : {
"application" : {
"name" : "MongoDB Shell"
},
"driver" : {
...
},
"os" : {
...
}
}
},
{
"desc": "GARBAGE_COLLECTION",
"garbageCollection": {
"databaseName": "testdb",
"collectionName": "testCollectionA"
},
"secs_running": 3,
"microsecs_running": NumberLong(3123456)
},
{
"desc": "GARBAGE_COLLECTION",
"garbageCollection": {
"databaseName": "testdb",
"collectionName": "testCollectionB"
},
"secs_running": 4,
"microsecs_running": NumberLong(4123456)
}
],
"ok" : 1
}
```
Berikuti ini adalah nilai valid untuk bidang `"desc"`:
+ **INTERNAL** — Tugas sistem internal seperti pembersihan kursor atau tugas pembersihan pengguna usang.
+ **TTLMonitor** — Urutan monitor Waktu untuk Tayang (TTL). Statusnya yang sedang berjalan tercermin di bidang `"active"`.
+ **GARBAGE\$1COLLECTION** — Urutan pengumpul sampah internal.
+ **CONN** — Kueri pengguna.
+ **CURSOR** — Operasi adalah kursor diam yang menunggu pengguna untuk memanggil perintah "getMore" untuk mendapatkan hasil batch berikutnya. Dalam keadaan ini, kursor mengonsumsi memori, tetapi tidak mengonsumsi komputasi apa pun.
Keluaran sebelumnya juga mendaftar semua kueri pengguna yang berjalan di sistem. Setiap kueri pengguna berjalan dalam konteks basis data dan koleksi, dan penyatuan keduanya disebut *namespace*. Namespace dari setiap kueri pengguna tersedia di bidang `"ns"`.
Kadang-kadang Anda perlu mendaftar semua kueri pengguna yang berjalan di namespace tertentu. Sehingga keluaran sebelumnya harus difilter pada bidang `"ns"`. Berikut ini adalah contoh kueri untuk mencapai keluaran untuk filter. Kueri mendaftar semua kueri pengguna yang saat ini berjalan di basis data `"db"` dan koleksi `"test"` (yaitu, namespace `"db.test"`).
```
db.adminCommand({aggregate: 1,
pipeline: [{$currentOp: {allUsers: true, idleConnections: true}},
{$match: {ns: {$eq: "db.test"}}}],
cursor: {}
});
```
Sebagai pengguna utama sistem, Anda dapat melihat kueri semua pengguna dan juga semua tugas sistem internal. Semua pengguna lain hanya dapat melihat kueri mereka masing-masing.
Jika jumlah total kueri dan tugas sistem internal melebihi ukuran kursor batch default , `mongo` shell secara otomatis menghasilkan sebuah objek iterator `'it'` untuk melihat sisa hasil. Tetap jalankan perintah `'it'` hingga semua hasil telah dikeluarkan.
## Bagaimana saya tahu kapan kueri membuat kemajuan?
Kueri pengguna dapat berjalan lambat akibat rencana kueri suboptimal, atau mereka dapat diblokir akibat kontensi sumber daya. Debugging kueri semacam itu adalah proses multi-langkah yang mungkin perlu menjalankan langkah yang sama beberapa kali.
Langkah pertama debugging adalah untuk mendaftar semua kueri yang berjalan lama atau diblokir. Kueri berikut iniendaftar semua kueri pengguna yang telah berjalan selama lebih dari 10 detik atau yang menunggu sumber daya.
```
db.adminCommand({aggregate: 1,
pipeline: [{$currentOp: {}},
{$match: {$or: [{secs_running: {$gt: 10}},
{WaitState: {$exists: true}}]}},
{$project: {_id:0,
opid: 1,
secs_running: 1,
WaitState: 1,
blockedOn: 1,
command: 1}}],
cursor: {}
});
```
Ulangi kueri sebelumnya secara berkala untuk menentukan apakah daftar kueri berubah dan untuk mengidentifikasi kueri yang berjalan lama atau diblokir.
Jika dokumen keluaran untuk kueri yang menjadi perhatian memiliki bidang `WaitState`, ini menunjukkan bahwa kontensi sumber daya adalah mengapa kueri berjalan lambat atau diblokir. Kontensi sumber daya dapat akibat I/O, tugas sistem internal, maupun kueri pengguna lainnya.
Keluaran dari operasi ini terlihat seperti berikut ini (format JSON).
```
{
"waitedMS" : NumberLong(0),
"cursor" : {
"firstBatch" : [
{
"opid" : 201,
"command" : {
"aggregate" : ...
},
"secs_running" : 208,
"WaitState" : "IO"
}
],
"id" : NumberLong(0),
"ns" : "admin.$cmd"
},
"ok" : 1
}
```
I/O dapat menjadi hambatan jika banyak kueri di seluruh koleksi yang berbeda berjalan bersamaan pada instans yang sama, atau jika ukuran instans terlalu kecil untuk set data tempat kueri berjalan. Jika kueri adalah kueri hanya baca, Anda dapat memitigasi situasi sebelumnya dengan memisahkan kueri untuk setiap koleksi di seluruh replika terpisah. Untuk pembaruan bersamaan di koleksi yang berbeda, atau ketika ukuran instans terlalu kecil untuk set data, Anda dapat memitigasi dengan menskalakan ke atas instans.
Jika kontensi sumber daya adalah akibat kueri pengguna lain, bidang `"blockedOn"` di dokumen keluaran akan memiliki `"opid"` dari kueri yang memengaruhi kueri ini. Dengan menggunakan `"opid"` ikuti rantai bidang `"WaitState"` dan `"blockedOn"` dari semua kueri untuk menemukan kueri pada kepala rantai.
Jika tugas kepala rantai adalah tugas internal, satu-satunya mitigasi dalam kasus ini akan mengakhiri kueri dan nantinya akan menjalankan kembali.
Berikut ini adalah keluaran contoh di mana kueri penemuan diblokir pada kunci koleksi yang dimiliki oleh tugas lain.
```
{
"inprog" : [
{
"client" : "...",
"desc" : "Conn",
"active" : true,
"killPending" : false,
"opid" : 75,
"ns" : "...",
"command" : {
"find" : "...",
"filter" : {
}
},
"op" : "query",
"$db" : "test",
"secs_running" : 9,
"microsecs_running" : NumberLong(9449440),
"threadId" : 24773,
"clientMetaData" : {
"application" : {
"name" : "MongoDB Shell"
},
"driver" : {
...
},
"os" : {
...
}
},
"WaitState" : "CollectionLock",
"blockedOn" : "INTERNAL"
},
{
"desc" : "INTERNAL"
},
{
"client" : "...",
...
"command" : {
"currentOp" : 1
},
...
}
],
"ok" : 1
}
```
Jika `"WaitState"` memiliki nilai `"Latch"`, `"SystemLock"`, `"BufferLock"`, `"BackgroundActivity"`, atau `"Other"`, sumber kontensi sumber daya adalah tugas sistem internal. Jika situasi terus berlangsung selama waktu yang lama, hanya mitigasi yang akan mengakhiri kueri dan nantinya akan menjalankan kembali.
## Bagaimana cara menentukan mengapa sistem tiba-tiba berjalan lambat?
Berikut ini adalah beberapa alasan umum mengapa sistem melambat:
+ Kontensi sumber daya yang berlebihan di antara kueri yang bersamaan
+ Jumlah kueri bersamaan yang aktif meningkat seiring waktu
+ Tugas sistem internal seperti `"GARBAGE_COLLECTION"`
Untuk memantau penggunaan sistem dari waktu ke waktu, jalankan kueri `"currentOp"` berikut ini secara berkala dan keluarkan hasil ke penyimpanan eksternal. Kueri menghitung jumlah kueri dan operasi di setiap namespace dalam sistem. Anda kemudian dapat menganalisis hasil penggunaan sistem untuk memahami beban pada sistem dan mengambil tindakan yang tepat.
```
db.adminCommand({aggregate: 1,
pipeline: [{$currentOp: {allUsers: true, idleConnections: true}},
{$group: {_id: {desc: "$desc", ns: "$ns", WaitState: "$WaitState"}, count: {$sum: 1}}}],
cursor: {}
});
```
Kueri ini mengembalikan agregat dari semua kueri yang berjalan di setiap namespace, semua tugas sistem internal, dan jumlah unik keadaan menunggu (jika ada) per namespace.
Keluaran dari operasi ini terlihat seperti berikut ini (format JSON).
```
{
"waitedMS" : NumberLong(0),
"cursor" : {
"firstBatch" : [
{
"_id" : {
"desc" : "Conn",
"ns" : "db.test",
"WaitState" : "CollectionLock"
},
"count" : 2
},
{
"_id" : {
"desc" : "Conn",
"ns" : "admin.$cmd"
},
"count" : 1
},
{
"_id" : {
"desc" : "TTLMonitor"
},
"count" : 1
}
],
"id" : NumberLong(0),
"ns" : "admin.$cmd"
},
"ok" : 1
}
```
Dalam keluaran sebelumnya, dua kueri pengguna dalam `"db.test"` namespace diblokir pada kunci koleksi: satu kueri di `"admin.$cmd"` namespace, dan satu tugas `"TTLMonitor"` internal.
Jika keluaran menunjukkan banyak kueri dengan memblokir keadaan tunggu, lihat [Bagaimana cara menemukan dan menghentikan kueri yang berjalan lama atau diblokir?](#user_diagnostics-query_terminating)
## Bagaimana cara menentukan penyebab pemanfaatan CPU yang tinggi pada satu atau lebih instance cluster?
Bagian berikut ini dapat membantu Anda mengidentifikasi penyebab pemanfaatan CPU instans yang tinggi. Hasil Anda dapat bervariasi bergantung pada beban kerja.
+ Untuk menentukan mengapa instans tiba-tiba berjalan lambat, lihat [Bagaimana cara menentukan mengapa sistem tiba-tiba berjalan lambat?](#user_diagnostics-speed_change)
+ Untuk mengidentifikasi dan mengakhiri kueri yang berjalan lamaa pada instans tertentu, lihat [Bagaimana cara menemukan dan menghentikan kueri yang berjalan lama atau diblokir?](#user_diagnostics-query_terminating)
+ Untuk memahami apakah kueri sedang berjalan, lihat [Bagaimana saya tahu kapan kueri membuat kemajuan?](#user_diagnostics-query_progressing)
+ Untuk menentukan mengapa kueri membutuhkan waktu yang lama untuk berjalan, lihat [Bagaimana saya bisa melihat rencana kueri dan mengoptimalkan kueri?](#user_diagnostics-query_plan)
+ Untuk melacak kueri yang berjalan lama dari waktu ke waktu, lihat [Membuat profil operasi Amazon DocumentDB](profiling.md).
Bergantung pada alasan untuk pemanfaatan CPU instans Anda yang tinggi, dengan melakukan satu atau lebih hal berikut ini dapat membantu.
+ Jika instans primer menunjukkan pemanfaatan CPU yang tinggi, tetapi instans replika tidak menunjukkannya, pertimbangkan untuk mendistribusikan lalu lintas baca di replika melalui pengaturan preferensi baca klien (sebagai contoh, `secondaryPreferred`). Untuk informasi selengkapnya, lihat [Menghubungkan ke Amazon DocumentDB sebagai set replika](connect-to-replica-set.md).
Dengan menggunakan replika untuk pembacaan dapat membuat penggunaan klaster sumber daya yang lebih baik dengan mengizinkan instans primer untuk memproses lebih banyak lalu lintas tulis. Pembacaan dari replika pada akhirnya adalah konsisten.
+ Jika pemanfaatan CPU yang tinggi adalah hasil dari beban kerja tulis Anda, mengubah ukuran instans klaster untuk jenis instans yang lebih besar meningkatkan jumlah inti CPU yang tersedia untuk layanan beban kerja. Untuk informasi selengkapnya, lihat [Contoh](what-is.md#what-is-db-instances) dan [Spesifikasi kelas instans](db-instance-classes.md#db-instance-class-specs).
+ Jika semua instans klaster menunjukkan pemanfaatan CPU yang tinggi, dan beban kerja menggunakan replika untuk pembacaan, akan menambahkan lebih banyak replika klaster akan meningkatkan sumber daya yang tersedia untuk lalu lintas baca. Untuk informasi selengkapnya, lihat [Menambahkan instance Amazon DocumentDB ke klaster](db-instance-add.md).
## Bagaimana cara menentukan kursor terbuka pada sebuah instance?
Ketika terhubung ke instans Amazon DocumentDB, Anda dapat menggunakan perintah `db.runCommand("listCursors")` untuk mendaftar kursor terbuka pada instans tersebut. Terdapat batas hingga 4.560 kursor aktif terbuka pada waktu tertentu pada instans Amazon DocumentDB tertentu, bergantung pada tipe instans. Umumnya disarankan untuk menutup kursor yang tidak lagi digunakan karena kursor memanfaatkan sumber daya pada instans dan memiliki batas atas. Lihat [Kuota dan batas Amazon DocumentDB](limits.md) untuk batas spesifik.
```
db.runCommand("listCursors")
```
## Bagaimana cara menentukan versi mesin Amazon DocumentDB saat ini?
Untuk menentukan versi mesin Amazon DocumentDB Anda saat ini, jalankan perintah berikut ini.
```
db.runCommand({getEngineVersion: 1})
```
Keluaran dari operasi ini terlihat seperti berikut ini (format JSON).
```
{ "engineVersion" : "2.x.x", "ok" : 1 }
```
**catatan**
Versi mesin untuk Amazon DocumentDB 3.6 adalah 1.xx, versi mesin untuk Amazon DocumentDB 4.0 adalah 2.xx, versi mesin untuk Amazon DocumentDB 5.0 adalah 3.xx, dan versi mesin untuk Amazon DocumentDB 8.0 adalah 4.xx.
## Bagaimana cara menganalisis penggunaan indeks dan mengidentifikasi indeks yang tidak digunakan?
Untuk mengidentifikasi indeks untuk koleksi tertentu, jalankan perintah berikut ini:
```
db.collection.getIndexes()
```
Untuk menganalisis berapa banyak indeks yang digunakan selama operasi yang dilakukan pada koleksi, `indexStats` perintah `collStats` dan dapat digunakan. Untuk melihat jumlah total pemindaian yang dilakukan menggunakan indeks (pemindaian indeks) dibandingkan dengan jumlah pemindaian yang dilakukan tanpa indeks (pemindaian koleksi), jalankan perintah berikut:
```
db.collection.stats()
```
Output untuk perintah ini mencakup nilai-nilai berikut:
+ **`idxScans`**- Jumlah pemindaian yang dilakukan pada koleksi ini menggunakan indeks.
+ **`collScans`**- Jumlah pemindaian yang dilakukan pada koleksi ini tanpa menggunakan indeks. Pemindaian ini akan melibatkan pemeriksaan dokumen dalam koleksi satu per satu.
+ **`lastReset`**- Waktu penghitung ini telah diatur ulang terakhir. Statistik yang disediakan oleh perintah ini diatur ulang saat starting/stopping cluster atau penskalaan up/down instance.
Rincian berapa banyak setiap indeks digunakan dapat ditemukan dalam output dari perintah berikut. Ini adalah praktik terbaik untuk secara teratur mengidentifikasi dan menghapus indeks yang tidak digunakan untuk meningkatkan kinerja dan mengurangi biaya, karena menghilangkan komputasi, penyimpanan, dan I/Os penggunaan yang tidak perlu untuk mempertahankan indeks.
```
db.collection.aggregate([{$indexStats:{}}]).pretty()
```
Output dari perintah ini memberikan nilai-nilai berikut untuk setiap indeks yang dibuat pada koleksi:
+ **`ops`**- Jumlah operasi yang menggunakan indeks. Jika beban kerja Anda telah berjalan selama waktu yang cukup lama dan Anda yakin bahwa beban kerja Anda dalam keadaan stabil, nilai `ops` sebesar nol akan menunjukkan bahwa indeks tidak digunakan sama sekali.
+ **`numDocsRead`**- Jumlah dokumen yang dibaca selama operasi menggunakan indeks ini.
+ **`since`**- Waktu sejak Amazon DocumentDB mulai mengumpulkan statistik tentang penggunaan indeks, yang biasanya merupakan nilai sejak restart database terakhir atau tindakan pemeliharaan.
+ **`size`**- Ukuran indeks ini dalam byte.
Contoh berikut adalah contoh output dari menjalankan perintah di atas:
```
{
"name" : "_id_",
"key" : {
"_id" : 1
},
"host" : "example-host.com:12345",
"size" : NumberLong(...),
"accesses" : {
"ops" : NumberLong(...),
"docsRead" : NumberLong(...),
"since" : ISODate("...")
},
"cacheStats" : {
"blksRead" : NumberLong(...),
"blksHit" : NumberLong(...),
"hitRatio" : ...
}
}
{
"name" : "x_1",
"key" : {
"x" : 1
},
"host" : "example-host.com:12345",
"size" : NumberLong(...),
"accesses" : {
"ops" : NumberLong(...),
"docsRead" : NumberLong(...),
"since" : ISODate("...")
},
"cacheStats" : {
"blksRead" : NumberLong(...),
"blksHit" : NumberLong(...),
"hitRatio" : ...
}
}
```
Untuk menentukan ukuran indeks keseluruhan untuk koleksi, jalankan perintah berikut ini:
```
db.collection.stats()
```
Untuk menghapus indeks yang tidak digunakan, jalankan perintah berikut ini:
```
db.collection.dropIndex("indexName")
```
## Bagaimana cara mengidentifikasi indeks yang hilang?
Anda dapat menggunakan [profiler Amazon DocumentDB untuk log kueri yang lambat](https://docs.aws.amazon.com//documentdb/latest/developerguide/profiling.html). Kueri yang muncul berulang kali di log kueri lambat mungkin menunjukkan bahwa indeks tambahan diperlukan untuk meningkatkan performa kueri tersebut.
Anda dapat mengidentifikasi peluang untuk indeks bermanfaat dengan mencari kueri berjalan lama yang memiliki satu atau lebih tahapan yang melakukan setidaknya satu `COLLSCAN` tahap, yang berarti bahwa tahap kueri harus membaca setiap dokumen dalam koleksi untuk memberikan respons terhadap kueri.
Contoh berikut ini menunjukkan kueri pada koleksi perjalanan taksi yang berjalan pada koleksi besar.
```
db.rides.count({"fare.totalAmount":{$gt:10.0}}))
```
Untuk menjalankan contoh ini, kueri harus melakukan pemindaian koleksi (yaitu membaca setiap dokumen tunggal dalam koleksi) karena tidak ada indeks pada bidang `fare.totalAmount`. Keluaran dari profiler Amazon DocumentDB untuk kueri ini terlihat seperti berikut ini:
```
{
...
"cursorExhausted": true,
"nreturned": 0,
"responseLength": 0,
"protocol": "op_query",
"millis": 300679,
"planSummary": "COLLSCAN",
"execStats": {
"stage": "COLLSCAN",
"nReturned": "0",
"executionTimeMillisEstimate": "300678.042"
},
"client": "172.31.5.63:53878",
"appName": "MongoDB Shell",
"user": "example"
}
```
Untuk mempercepat kueri dalam contoh ini, Anda ingin membuat indeks pada `fare.totalAmount`, sebagaimana ditunjukkan di bawah ini.
```
db.rides.createIndex( {"fare.totalAmount": 1}, {background: true} )
```
**catatan**
Indeks yang dibuat di latar depan (artinya jika opsi `{background:true}` tidak disediakan saat membuat indeks) ambil kunci tulis eksklusif, yang mencegah aplikasi agar tidak menulis data ke koleksi hingga pembuatan indeks selesai. Waspadalah dampak potensial ini saat membuat indeks pada klaster produksi. Saat membuat indeks, kami menyarankan pengaturan `{background:true}`.
Secara umum, Anda ingin membuat indeks pada bidang yang memiliki kardinalitas tinggi (sebagai contoh, sejumlah besar nilai unik). Membuat indeks di bidang dengan kardinalitas rendah dapat menghasilkan indeks besar yang tidak digunakan. Pengoptimal kueri Amazon DocumentDB menganggap ukuran keseluruhan koleksi dan selektivitas indeks saat membuat rencana kueri. Ada kalanya Anda akan melihat prosesor kueri memilih `COLLSCAN` bahkan ketika ada indeks. Hal ini terjadi ketika kueri prosesor memperkirakan bahwa pemanfaatan indeks tidak akan menghasilkan keuntungan performa pada saat memindai seluruh koleksi. Jika Anda ingin memaksa prosesor kueri untuk memanfaatkan indeks tertentu, Anda dapat menggunakan operator `hint()` sebagaimana ditunjukkan di bawah ini.
```
db.collection.find().hint("indexName")
```
## Bagaimana cara menentukan pengumpulan database bloat?
Collection bloat terjadi ketika ukuran koleksi menjadi lebih besar karena akumulasi dokumen mati atau usang atau fragmentasi dalam halaman database. Persentase yang dilaporkan mewakili jumlah ruang dokumen yang dapat digunakan oleh dokumen future. Bloat ini menghabiskan ruang di cache buffer dan penyimpanan. Untuk menghapus bloat, koleksi harus dimuat ulang baik melalui dump/restore atau menggunakan migrasi loop-back dan switchover selama jendela pemeliharaan.
**Example Contoh**
Jalankan perintah berikut untuk menentukan penyimpanan yang tidak digunakan untuk koleksi Anda:
```
db.runCommand({collStats:'coll'})
```
Hasilnya terlihat mirip dengan ini:
```
{
"ns" : "test.coll",
"count" : 7500,
"size" : 23250,
"avgObjSize" : 31,
"storageSize" : 106496,
"unusedStorageSize" : {
"unusedBytes" : 16384,
"unusedPercent" : 25.12
},
"compression" : {
"enable" : false
},
"capped" : false,
"nindexes" : 1,
"totalIndexSize" : 57344,
"indexSizes" : {
"_id_" : 57344
},
"collScans" : 4,
"idxScans" : 10000,
"opCounter" : {
"numDocsIns" : 1000,
"numDocsUpd" : 0,
"numDocsDel" : 250
},
"cacheStats" : {
"collBlksHit" : 3570,
"collBlksRead" : 8,
"collHitRatio" : 99.7765,
"idxBlksHit" : 12293,
"idxBlksRead" : 6,
"idxHitRatio" : 99.9513
},
"lastReset" : "2024-12-18 00:30:21.552019+00",
"ok" : 1,
"operationTime" : Timestamp(1734632375, 1)
}
```
## Ringkasan pertanyaan yang berguna
Kueri berikut ini dapat berguna untuk memantau peforma dan pemanfaatan sumber daya di Amazon DocumentDB.
+ Gunakan perintah berikut untuk melihat statistik tentang koleksi tertentu, termasuk penghitung operasi, statistik cache, statistik akses, dan statistik ukuran:
```
db.collection.stats()
```
+ Gunakan perintah berikut untuk melihat statistik tentang setiap indeks yang dibuat pada koleksi termasuk ukuran indeks, statistik cache khusus indeks, dan statistik penggunaan indeks:
```
db.collection.aggregate([{$indexStats:{}}]).pretty()
```
+ Gunakan kueri berikut ini untuk mendaftar semua aktivitas.
```
db.adminCommand({currentOp: 1, $all: 1});
```
+ Kode berikut ini mencantumkan semua kueri yang berjalan lama atau diblokir.
```
db.adminCommand({aggregate: 1,
pipeline: [{$currentOp: {}},
{$match: {$or: [{secs_running: {$gt: 10}},
{WaitState: {$exists: true}}]}},
{$project: {_id:0,
opid: 1,
secs_running: 1,
WaitState: 1,
blockedOn: 1,
command: 1}}],
cursor: {}
});
```
+ Kode berikut ini mengakhiri kueri.
```
db.adminCommand({killOp: 1, op: });
```
+ Gunakan kode berikut ini untuk mendapatkan tampilan agregat dari keadaan sistem.
```
db.adminCommand({aggregate: 1,
pipeline: [{$currentOp: {allUsers: true, idleConnections: true}},
{$group: {_id: {desc: "$desc", ns: "$ns", WaitState: "$WaitState"}, count: {$sum: 1}}}],
cursor: {}
});
```
# 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 memungkinkan isolasi transaksi, mencegah perubahan satu transaksi muncul di transaksi lain.
**Topics**
+ [Memahami Pengumpulan Sampah di Amazon DocumentDB](#understanding-garbage-collection)
+ [Proses pengumpulan sampah](#garbage-collection-process)
+ [Arsitektur penyimpanan dan penyimpanan yang diperluas](#storage-architecture)
+ [Memantau pengumpulan sampah](#monitoring-garbage-collection)
+ [Contoh keluaran CollStats](#example-collstats-output)
+ [Pertanyaan umum](#garbage-collection-faq)
## 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. Seperti banyak database modern, arsitektur MVCC Amazon DocumentDB membuat versi dokumen dan indeks baru dengan setiap pembaruan. Setiap operasi penulisan menggunakan ID MVCC unik dari penghitung terbatas. Ini IDs mengidentifikasi transaksi mana yang dimiliki versi dokumen dan apakah telah dilakukan atau dibatalkan. Seiring waktu, versi lama ini dan MVCC mereka IDs menumpuk, membutuhkan pembersihan 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 secara 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.
1. **Memory loading** — Dokumen lama dan entri indeks dimuat ke dalam memori jika belum ada.
1. **Penghapusan** - Versi usang dihapus secara permanen untuk merebut kembali ruang penyimpanan.
1. **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.
## Arsitektur penyimpanan dan penyimpanan yang diperluas
Amazon DocumentDB menggunakan arsitektur penyimpanan canggih yang memisahkan penyimpanan dokumen menjadi dua segmen berbeda:
### Segmen penyimpanan dasar
Segmen penyimpanan dasar berisi data dokumen utama dan metadata. Segmen ini menyimpan:
+ Konten dokumen yang sesuai dengan ukuran halaman standar (8 KB).
+ Mendokumentasikan metadata dan informasi struktur.
+ Indeks primer dan entri mereka.
+ Statistik dan konfigurasi tingkat koleksi.
### Segmen penyimpanan yang diperluas
Segmen penyimpanan yang diperluas menggunakan toko objek dokumen besar khusus yang dirancang untuk menangani dokumen yang melebihi ukuran halaman penyimpanan standar. Segmen ini menyediakan:
+ **Penanganan Dokumen Besar yang Efisien** — Dokumen yang lebih besar dari ambang penyimpanan dasar secara otomatis dipindahkan ke segmen penyimpanan yang diperluas.
+ **Tata Letak Penyimpanan yang Dioptimalkan** - Segmen ini menggunakan format penyimpanan berbeda yang dioptimalkan untuk objek besar, mengurangi fragmentasi dan meningkatkan pola akses.
+ **Pengumpulan Sampah Independen** — Segmen penyimpanan yang diperluas memiliki proses pengumpulan sampah sendiri yang dapat berjalan secara independen dari pembersihan penyimpanan dasar.
+ **Akses Transparan** — Aplikasi mengakses dokumen besar dengan mulus tanpa perlu mengetahui segmen penyimpanan mana yang berisi data.
Segmen penyimpanan yang diperluas sangat bermanfaat untuk:
+ Koleksi dengan dokumen yang berisi array tertanam besar.
+ Dokumen dengan struktur bersarang yang luas.
+ Koleksi menyimpan data biner atau bidang teks besar.
+ Aplikasi dengan ukuran dokumen campuran di mana beberapa dokumen secara signifikan melebihi ukuran rata-rata.
## Memantau pengumpulan sampah
### Metrik tingkat cluster
**`AvailableMVCCIds`**
+ **Lokasi** - Amazon CloudWatch
+ **Deskripsi** — Penghitung yang menunjukkan jumlah operasi tulis yang tersisa yang tersedia dari batas maksimum 1,8 miliar. 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.
**`LongestActiveGCRuntime`**
+ **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** — Bandingkan dengan data `gcRuntimeStats` historis untuk mengidentifikasi perilaku pengumpulan sampah yang tidak normal, seperti runtime yang diperpanjang selama penghapusan massal.
### Metrik tingkat pengumpulan
**`MVCCIDStats: MVCCIdScale`**
+ **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.
**penting**
`gcRuntimeStats`,`documentFragmentStats`, dan pemecahan metrik tingkat koleksi menjadi `storageSegmentBase` dan hanya `storageSegmentExtended` tersedia untuk Amazon DocumentDB 8.0.
**`storageSizeStats`**
+ **Lokasi** - Perintah CollStats Database
+ **Deskripsi** - Memberikan rincian rinci pemanfaatan penyimpanan di segmen penyimpanan yang berbeda:
+ `storageSegmentBase`— Penyimpanan yang digunakan oleh segmen penyimpanan dasar untuk dokumen standar
+ `storageSegmentExtended`— Penyimpanan yang digunakan oleh segmen penyimpanan yang diperluas untuk dokumen besar
+ **Penggunaan** - Membantu mengidentifikasi koleksi dengan penyimpanan dokumen besar yang signifikan dan memahami pola distribusi penyimpanan.
**`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 ini menyediakan total gabungan dan kerusakan per segmen:
+ Gabungan `unusedBytes` dan `unusedPercent` di semua segmen penyimpanan
+ `storageSegmentBase`— Ruang yang tidak terpakai khususnya di segmen penyimpanan dasar
+ `storageSegmentExtended`— Ruang yang tidak terpakai khususnya di segmen penyimpanan yang diperluas
**`documentFragmentStats`**
+ **Lokasi** - Perintah CollStats Database
+ **Deskripsi** — Memberikan informasi rinci tentang fragmen dokumen dan data mati dalam koleksi. Fragmen dokumen mewakili unit penyimpanan internal yang digunakan oleh mesin database, dan fragmen mati menunjukkan data yang tidak lagi dapat diakses tetapi belum direklamasi. Metrik ini meliputi:
+ `totalDocFragmentsCount`— Jumlah total fragmen dokumen dalam koleksi
+ `deadDocFragmentsCount`— Jumlah fragmen yang berisi data mati (tidak dapat diakses)
+ `deadDocFragmentsPercent`— Persentase fragmen yang berisi data mati
+ `deadDocFragmentBytes`— Perkiraan byte yang dikonsumsi oleh fragmen dokumen mati
+ Rincian per segmen untuk dan `storageSegmentBase` `storageSegmentExtended`
+ **Penggunaan** — Pantau metrik ini untuk memahami efektivitas pengumpulan sampah dan mengidentifikasi koleksi yang mungkin mendapat manfaat dari operasi pemeliharaan. Persentase fragmen mati yang tinggi menunjukkan bahwa pengumpulan sampah mungkin tertinggal atau bahwa pengumpulan akan mendapat manfaat dari pengoptimalan.
### 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 keluaran CollStats
Contoh berikut menunjukkan `collStats` output tipikal dengan pengumpulan sampah dan metrik penyimpanan:
```
{
"ns" : "Mvcc_consumption_test_db.mvcc_test_collection",
"MVCCIdStats" : {
"MVCCIdScale" : 0.03
},
"gcRuntimeStats" : {
"numRuns" : 1,
"historicalAvgRuntime" : 3295,
"historicalMaxRuntime" : 3295,
"lastRuntime" : 3295,
"lastRuntimeStart" : ISODate("2025-06-24T08:47:14Z")
},
"documentFragmentStats" : {
"totalDocFragmentsCount" : 45000000,
"deadDocFragmentsCount" : 2250000,
"deadDocFragmentsPercent" : 5.0,
"deadDocFragmentBytes" : 98304000,
"storageSegmentBase" : {
"totalDocFragmentsCount" : 30000000,
"deadDocFragmentsCount" : 1500000,
"deadDocFragmentsPercent" : 5.0,
"deadDocFragmentBytes" : 65536000
},
"storageSegmentExtended" : {
"totalDocFragmentsCount" : 15000000,
"deadDocFragmentsCount" : 750000,
"deadDocFragmentsPercent" : 5.0,
"deadDocFragmentBytes" : 32768000
}
},
"collScans" : 14,
"count" : 30000000,
"size" : 1320000000,
"avgObjSize" : 44,
"storageSize" : 6461497344,
"storageSizeStats" : {
"storageSegmentBase" : 4307664896,
"storageSegmentExtended" : 2153832448
},
"capped" : false,
"nindexes" : 2,
"totalIndexSize" : 9649553408,
"indexSizes" : {
"_id_" : 1910661120,
"c_1" : 7738892288
},
"unusedStorageSize" : {
"unusedBytes" : 4201881600,
"unusedPercent" : 65.05,
"storageSegmentBase" : {
"unusedBytes" : 2801254400,
"unusedPercent" : 65.05
},
"storageSegmentExtended" : {
"unusedBytes" : 1400627200,
"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
### Bagaimana cara mengidentifikasi jika pengumpulan sampah tidak bekerja secara efisien?
Pantau tanda-tanda peringatan ini yang menunjukkan pengumpulan sampah yang tidak efisien:
+ **Excess Collection Bloat** — `unusedStorageSize` Metrik yang terus meningkat selama penulisan berat atau penghapusan massal, terutama dengan indeks besar.
+ **Persentase Fragmen Mati Tinggi** - `documentFragmentStats` menunjukkan `deadDocFragmentsPercent` nilai tinggi secara konsisten (di atas 10-15%).
+ **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`
+ **Elevated GC Processing** — Tinggi `LongestActiveGCRuntime` 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 hanya-baca sementara jika MVCC habis IDs .
+ Penggunaan sumber daya yang lebih tinggi selama proses pengumpulan intensif, terutama pada instance yang lebih kecil.
+ Mengurangi efisiensi dalam operasi segmen penyimpanan yang diperluas untuk dokumen besar.
### 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 Amazon untuk `AvailableMVCCIds` 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. Perlu diingat 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 saat pengumpulan sampah menyelesaikan pekerjaannya.
Penting juga untuk memantau `LongestActiveGCRuntime` metrik melalui Amazon CloudWatch. Metrik ini, bersama dengan`gcRuntimeStats`, membantu Anda memahami seberapa efisien kinerja pengumpulan sampah di seluruh sistem Anda.
Untuk pemantauan tingkat pengumpulan, fokuslah pada metrik utama ini:
+ `MVCCIdScale`Perhatikan peningkatan nilai yang menunjukkan MVCC IDs menua dan mungkin perlu perhatian.
+ `gcRuntimeStats`— Identifikasi proses pengumpulan sampah yang memakan waktu yang sangat lama atau diperpanjang selama beberapa hari.
+ `documentFragmentStats`— `deadDocFragmentsPercent` Nilai monitor - persentase tinggi secara konsisten (di atas 10-15%) dapat mengindikasikan pengumpulan sampah tertinggal.
+ `storageSizeStats`dan `unusedStorageSize` — Lacak pola pemanfaatan penyimpanan dan identifikasi koleksi dengan ruang signifikan yang tidak terpakai di kedua segmen penyimpanan.
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 `AvailableMVCCIds` jatuh di bawah 1,3 miliar?
Jika `AvailableMVCCIds` metrik Anda turun di bawah 1,3 miliar, kami sarankan untuk segera mengambil tindakan untuk mencegah klaster Anda memasuki mode hanya-baca. Kami sarankan terlebih dahulu meningkatkan ukuran instans Anda untuk menyediakan lebih banyak sumber daya komputasi kepada pengumpul sampah. Ini adalah rekomendasi utama kami karena 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 `MVCCIdScale` metrik untuk mengidentifikasi koleksi spesifik mana yang berisi MVCC lama IDs yang perlu diperhatikan. Selain itu, pantau `documentFragmentStats` untuk mengidentifikasi koleksi dengan persentase fragmen mati tinggi yang mungkin berkontribusi terhadap inefisiensi pengumpulan sampah.
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 `AvailableMVCCIds` metrik dengan cermat untuk memastikan tindakan Anda memiliki efek yang diinginkan. Cluster Anda dianggap sehat setelah `AvailableMVCCIds` 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.