Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
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.
Topik
- Bagaimana cara menentukan jumlah operasi penyisipan, pembaruan, dan penghapusan yang dilakukan pada koleksi saya melalui Mongo API?
- Bagaimana cara menganalisis kinerja cache?
- Bagaimana cara menemukan dan menghentikan kueri yang berjalan lama atau diblokir?
- Bagaimana saya bisa melihat rencana kueri dan mengoptimalkan kueri?
- Bagaimana saya bisa melihat rencana kueri dalam cluster elastis?
- Bagaimana cara saya mencantumkan semua operasi yang berjalan pada sebuah instance?
- Bagaimana saya tahu kapan kueri membuat kemajuan?
- Bagaimana cara menentukan mengapa sistem tiba-tiba berjalan lambat?
- Bagaimana cara menentukan penyebab pemanfaatan CPU yang tinggi pada satu atau lebih instance cluster?
- Bagaimana cara menentukan kursor terbuka pada sebuah instance?
- Bagaimana cara menentukan versi mesin Amazon DocumentDB saat ini?
- Bagaimana cara menganalisis penggunaan indeks dan mengidentifikasi indeks yang tidak digunakan?
- Bagaimana cara mengidentifikasi indeks yang hilang?
- Ringkasan pertanyaan yang berguna
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
insertManyperintahinsertdan, serta dokumen yang dimasukkan oleh upsert. -
numDocsUpd- Jumlah pembaruan dokumen dalam koleksi ini. Ini termasuk dokumen yang diperbarui menggunakan
findAndModifyperintahupdatedan. -
numDocsDel- Jumlah dokumen yang dihapus dari koleksi ini. Ini termasuk dokumen yang dihapus menggunakan
deleteOne,deleteMany,remove, danfindAndModifyperintah. -
LastReset - Waktu penghitung ini telah diatur ulang terakhir. Statistik yang disediakan oleh perintah ini diatur ulang saat memulai/menghentikan cluster atau menskalakan naik/turun 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 diMemantau Amazon DocumentDB dengan CloudWatch.
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 olehdb.collection.stats()diatur ulang saat memulai/menghentikan cluster atau menskalakan naik/turun 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
Temukan
opidkueri.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 }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: {<query document>}})
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 kueri 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-shard. 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_MERGE “dalam setiap pecahan. Hasil di seluruh pecahan kemudian digabungkan bersama pada tahap” SHARD_MERGE “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.)
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_COLLECTION— 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?
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?
-
Untuk mengidentifikasi dan mengakhiri kueri yang berjalan lamaa pada instans tertentu, lihat Bagaimana cara menemukan dan menghentikan kueri yang berjalan lama atau diblokir?
-
Untuk memahami apakah kueri sedang berjalan, lihat Bagaimana saya tahu kapan kueri membuat kemajuan?
-
Untuk menentukan mengapa kueri membutuhkan waktu yang lama untuk berjalan, lihat Bagaimana saya bisa melihat rencana kueri dan mengoptimalkan kueri?
-
Untuk melacak kueri yang berjalan lama dari waktu ke waktu, lihat Membuat Profil Operasi Amazon DocumentDB.
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.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. Lihat informasi yang lebih lengkap di Instans dan Spesifikasi Kelas Instans.
-
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 cluster.
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 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.x.x dan versi mesin untuk Amazon DocumentDB 4.0 adalah 2.x.x.
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 memulai/menghentikan cluster atau menskalakan naik/turun 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/O yang tidak perlu yang digunakan 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, nilaiopssebesar 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. 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 yang bermanfaat dengan mencari kueri yang berjalan lama yang memiliki satu atau lebih tahapan yang melakukan setidaknya satu tahap COLLSCAN, yang berarti bahwa kueri tahap tersebut harus membaca setiap dokumen dalam koleksi untuk menyediakan 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")
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:<opid of running or blocked query>}); -
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: {} });
