ApsaraDB for MongoDB：Saran Optimasi untuk Parameter

operationProfiling.mode

• Versi Utama yang Didukung: MongoDB 3.0 dan versi lebih baru.

• Paksa Restart setelah Modifikasi Parameter: Diperlukan.

• Nilai Default: off.

• Fungsi: Menentukan tingkat operasi yang diprofil oleh query profiler.

• Masalah:

  • Jika parameter ini disetel ke all atau slowOp, dan sejumlah besar log query lambat dihasilkan, performa instance akan menurun.

  • Beberapa pengguna mungkin bingung karena adanya koleksi system.profile dalam database ketika mereka lupa menonaktifkan query profiler.

  • Beberapa pengguna juga mungkin salah paham bahwa mereka perlu menyetel parameter ini ke slowOp untuk menghasilkan log query lambat.

• Saran Optimasi:

  Kami merekomendasikan agar Anda mempertahankan nilai default dari parameter ini. Jika Anda mengaktifkan query profiler, performa instance akan menurun. Log query lambat umumnya memberikan informasi analisis serupa. Aktifkan query profiler jika diperlukan dan nonaktifkan secara tepat waktu setelah analisis query selesai. Untuk informasi lebih lanjut tentang database profiler, lihat Profiler Overhead.

operationProfiling.slowOpThresholdMs

• Versi Utama yang Didukung: MongoDB 3.0 dan versi lebih baru.

• Paksa Restart setelah Modifikasi Parameter: Tidak diperlukan.

• Nilai Default: 100.

• Fungsi: Menentukan ambang batas yang digunakan untuk mengidentifikasi query lambat.

• Masalah:

  • Jika parameter ini disetel terlalu kecil, sejumlah besar log query lambat dan log audit tambahan dihasilkan. Ini memperpanjang waktu yang dibutuhkan untuk analisis query lambat.

  • Jika parameter ini disetel terlalu besar, banyak query lambat tidak dicatat dalam log. Ini juga memperpanjang waktu yang dibutuhkan untuk analisis query lambat.

• Saran Optimasi: Tingkatkan atau kurangi nilai parameter berdasarkan kebutuhan bisnis Anda. Kami merekomendasikan agar Anda menyetel parameter ini ke nilai yang lebih besar dari durasi rata-rata query utama untuk bisnis Anda. Contoh:

  • Anggaplah durasi query harian dalam bisnis yang sensitif terhadap latensi query hanya sekitar 30 milidetik. Untuk memfasilitasi analisis query lambat dengan jitter sesaat, turunkan nilai parameter menjadi 50.

  • Anggaplah durasi query harian dalam bisnis yang melibatkan query analitik berkisar antara 300 hingga 400 milidetik. Untuk mengurangi jumlah log query lambat yang dihasilkan untuk query harian, tingkatkan nilai parameter menjadi 500.

replication.oplogGlobalIdEnabled

• Versi Utama yang Didukung: MongoDB 4.0 dan versi lebih baru.

• Paksa Restart setelah Modifikasi Parameter: Diperlukan.

• Nilai Default: false.

• Fungsi: Menentukan apakah akan mengaktifkan ID global (GID) untuk mempercepat sinkronisasi dua arah yang dilakukan oleh Data Transmission Service (DTS) atau mongoShake. Parameter ini adalah parameter yang dikembangkan sendiri. GID dirancang untuk memperbaiki masalah sinkronisasi melingkar yang terjadi dalam sinkronisasi dua arah.

• Saran Optimasi: Aktifkan parameter ini hanya ketika sinkronisasi dua arah diperlukan. Parameter ini mulai berlaku hanya setelah instance Anda di-restart. Kami merekomendasikan agar Anda mengubah parameter ini selama jam-jam sepi.

replication.oplogSizeMB

• Versi Utama yang Didukung: MongoDB 3.0 dan versi lebih baru.

• Paksa Restart setelah Modifikasi Parameter: Tidak diperlukan.

• Nilai Default: 10% dari ukuran disk. Sebagai contoh, jika ukuran disk instance Anda adalah 500 GB, nilai parameter aslinya adalah 51200, yang sama dengan 50 GB.

• Fungsi: Menentukan ukuran maksimum dari koleksi oplog yang menyimpan log sinkronisasi logis.

• Masalah: Jika parameter ini disetel terlalu kecil, node sekunder tidak dapat mengikuti node lain dan memasuki status RECOVERING. Selain itu, backup log tidak dapat menyimpan semua entri oplog, yang mengakibatkan hilangnya data dalam entri oplog dan gagalnya pemulihan pada titik waktu tertentu.

• Saran Optimasi: Kami merekomendasikan agar Anda mempertahankan nilai default dari parameter ini. Jangan kurangi nilai parameter. Tingkatkan nilai parameter jika diperlukan. Tingkatkan nilai parameter dalam skenario di mana sejumlah kecil data dengan pembaruan sering diproses dan sejumlah besar entri oplog dihasilkan. Dengan cara ini, oplog dapat menyimpan catatan oplog untuk periode waktu yang lebih lama, yang menghindari hilangnya data dalam entri oplog. Praktik terbaik adalah menyetel ukuran oplog ke nilai yang memungkinkan koleksi oplog menyimpan setidaknya satu jam entri oplog.

setParameter.cursorTimeoutMillis

• Versi Utama yang Didukung: MongoDB 3.0 dan versi lebih baru.

• Paksa Restart setelah Modifikasi Parameter: Tidak diperlukan.

• Nilai Default: 600000, yang sama dengan 10 menit.

• Fungsi: Menentukan ambang kedaluwarsa dari cursor idle. Unit: milidetik. Jika waktu idle cursor melebihi ambang ini, ApsaraDB for MongoDB secara otomatis menghapus cursor.

• Masalah: Jika Anda mencoba mengakses cursor yang sudah kedaluwarsa dan dihapus, klien Anda akan menerima kesalahan dalam format berikut:

  Pesan: "cursor id xxxxxxx not found"
  KodeKesalahan: CursorNotFound(43)

• Saran Optimasi: Kami merekomendasikan agar Anda tidak meningkatkan nilai parameter ini. Untuk mengurangi overhead sumber daya dari cursor idle, kurangi nilai parameter ini. Sebagai contoh, Anda dapat menurunkan nilai parameter menjadi 300000. Hindari cursor yang idle untuk jangka waktu lama dalam semua skenario.

setParameter.flowControlTargetLagSeconds

• Versi Utama yang Didukung: MongoDB 4.2 dan versi lebih baru.

• Paksa Restart setelah Modifikasi Parameter: Tidak diperlukan.

• Nilai Default: 10.

• Fungsi: Menentukan ambang batas untuk memicu mekanisme flowControl. Mekanisme ini dirancang untuk memastikan bahwa sebagian besar data dapat dikomit dalam jumlah detik yang ditentukan. Untuk informasi lebih lanjut, lihat Replication Lag and Flow Control.

• Masalah: Log query lambat serupa dengan yang berikut ini dihasilkan, dan waktu respons permintaan meningkat. Dalam log berikut, nilai parameter durationMillis pada dasarnya sama dengan nilai parameter flowControl.timeAcquiringMicros, yang menunjukkan bahwa query lambat terutama disebabkan oleh mekanisme flowControl.

  {
    "t": {
      "$date": "2024-04-25T13:28:45.840+08:00"
    },
    "s": "I",
    "c": "WRITE",
    "id": 51803,
    "ctx": "conn199253",
    "msg": "Slow query",
    "attr": {
      "type": "update",
      "ns": "xxx.xxxxx",
      "command": ...,
      "planSummary": "IDHACK",
      "totalOplogSlotDurationMicros": 61,
      "keysExamined": 1,
      "docsExamined": 1,
      "nMatched": 1,
      "nModified": 1,
      "nUpserted": 0,
      "keysInserted": 0,
      "keysDeleted": 0,
      "numYields": 0,
      "locks": ...,
      "flowControl": {
        "acquireCount": 1,
        "acquireWaitCount": 1,
        "timeAcquiringMicros": 959000
      },
      "readConcern": {
        "level": "local",
        "provenance": "implicitDefault"
      },
      "storage": {},
      "cpuNanos": 258845,
      "remote": "172.16.6.38:52368",
      "durationMillis": 959
    }
  }
  

• Saran Optimasi: Tingkatkan nilai parameter untuk mengurangi sensitivitas mekanisme flowControl. Jika permintaan masih sering dibatasi setelah Anda meningkatkan nilai parameter, instance Anda mengalami hambatan performa dalam hal sinkronisasi data antara instance utama dan sekunder. Dalam hal ini, Anda perlu menganalisis masalah ini lebih lanjut dan mengadopsi metode lain untuk memperbaiki masalah tersebut. Sebagai contoh, Anda dapat meningkatkan konfigurasi instance atau menyetel write concern ke majority.

setParameter.oplogFetcherUsesExhaust

• Versi Utama yang Didukung: MongoDB 4.4 dan versi lebih baru.

• Paksa Restart setelah Modifikasi Parameter: Diperlukan.

• Nilai Default: true.

• Fungsi: Menentukan apakah akan mengaktifkan replikasi aliran. Untuk informasi lebih lanjut, lihat Streaming Replication. Jika Anda menonaktifkan replikasi aliran, sinkronisasi data antara instance utama dan sekunder kembali ke metode penarikan data yang sama seperti versi sebelumnya. Ini berarti node sekunder mengirim permintaan ke sumber sinkronisasi untuk mendapatkan batch entri oplog dan kemudian menunggu respons. Dengan cara ini, setiap batch entri oplog memerlukan interaksi bolak-balik melalui jaringan.

• Masalah: Replikasi aliran dapat menghasilkan overhead performa dan bandwidth jaringan tambahan dalam beberapa skenario.

• Saran Optimasi: Kami merekomendasikan agar Anda tidak menyesuaikan nilai parameter ini. Replikasi aliran dapat mengurangi latensi replikasi dalam lingkungan jaringan beban tinggi dan latensi tinggi. Namun, ini juga menciptakan risiko kehilangan data yang ditulis ketika node utama dengan write concern {w:1} crash, dan latensi tulis ketika write concern disetel ke level yang bergantung pada replikasi utama/sekunder, seperti {w:majority atau {w:>1}.

setParameter.maxTransactionLockRequestTimeoutMillis

• Versi Utama yang Didukung: MongoDB 4.0 dan versi lebih baru.

• Paksa Restart setelah Modifikasi Parameter: Tidak diperlukan.

• Nilai Default: 5.

• Fungsi: Menentukan periode timeout untuk transaksi menunggu untuk mendapatkan kunci yang diperlukan oleh operasi dalam transaksi. Unit: milidetik. Jika operasi dalam transaksi tidak dapat mendapatkan kunci yang diperlukan dalam periode waktu tertentu, sistem secara otomatis membatalkan transaksi.

• Masalah: Pesan kesalahan berikut yang menunjukkan timeout untuk mendapatkan kunci ditampilkan dalam log atau klien Anda. Driver versi terbaru secara otomatis mencoba lagi ketika mereka menerima kesalahan TransientTransactionError. Oleh karena itu, kesalahan ini mungkin hanya muncul dalam log dan tidak terdeteksi oleh klien Anda.

  Pesan: "Tidak dapat memperoleh kunci '{8442595743001781021: Database, 1525066715360699165}' dalam max lock request timeout '5ms' milidetik."
  KodeKesalahan: LockTimeout(24)

• Saran Optimasi: Jika klien Anda sering menerima kesalahan seperti ini, Anda dapat meningkatkan nilai parameter. Ini mengurangi frekuensi pembatalan transaksi yang disebabkan oleh kegagalan untuk segera mendapatkan kunci konkuren. Namun, ini menunda pembatalan transaksi deadlock. Jika masalah di atas tetap ada setelah Anda meningkatkan nilai parameter, kami merekomendasikan agar Anda tidak meningkatkan nilai parameter lagi. Anda perlu mengoptimalkan logika bisnis sebagai gantinya. Sebagai contoh, Anda perlu menghindari modifikasi konkuren pada dokumen yang sama dalam transaksi, meninjau operasi dalam transaksi, dan memeriksa apakah transaksi berisi operasi yang menempati kunci untuk jangka waktu lama, seperti operasi DDL dan query yang perlu dioptimalkan.

setParameter.replWriterThreadCount

• Versi Utama yang Didukung: MongoDB 3.2 dan versi lebih baru.

• Paksa Restart setelah Modifikasi Parameter: Diperlukan.

• Nilai Default: 16.

• Fungsi: Menentukan jumlah maksimum thread yang digunakan untuk melakukan operasi replikasi secara paralel saat menyinkronkan antara instance utama dan sekunder. Jumlah maksimum thread yang digunakan dibatasi hingga dua kali jumlah core CPU.

• Masalah: Latensi pada node sekunder meningkat karena penundaan sinkronisasi data antara instance utama dan sekunder dalam skenario ekstrem.

• Saran Optimasi: Dalam kebanyakan kasus, kami merekomendasikan agar Anda tidak menyesuaikan nilai parameter ini. Dalam kasus khusus, kami merekomendasikan agar Anda membuat penyesuaian berdasarkan saran insinyur R&D Alibaba Cloud.

setParameter.tcmallocAggressiveMemoryDecommit

• Versi Utama yang Didukung: MongoDB 4.2 dan versi lebih baru.

• Paksa Restart setelah Modifikasi Parameter: Tidak diperlukan.

• Nilai Default: 0, yang menunjukkan bahwa strategi reclaim agresif TCMalloc dinonaktifkan.

• Fungsi: Menentukan apakah akan mengaktifkan strategi reclaim agresif TCMalloc. ApsaraDB for MongoDB menggunakan TCMalloc sebagai alokator memori. Setelah Anda mengaktifkan strategi ini, ApsaraDB for MongoDB mencoba menggabungkan blok memori bebas yang berdekatan dan mengembalikan sebagian memori ke sistem operasi.

• Masalah:

  • Kesalahan out-of-memory (OOM) dikembalikan karena memori mongod tidak dapat direklaim secara tepat waktu karena konsumsi memori yang berlebihan dari permintaan query.

  • Dengan penggunaan memori yang terus-menerus, fragmentasi memori heap meningkat. Dalam hal ini, penggunaan memori melebihi 80% dan meningkat secara perlahan dan stabil.

• Saran Optimasi: Dalam kebanyakan kasus, kami merekomendasikan agar Anda tidak menyesuaikan nilai parameter ini. Jika Anda mengalami masalah terkait memori, sesuaikan nilai parameter ini selama jam-jam sepi.

setParameter.transactionLifetimeLimitSeconds

• Versi Utama yang Didukung: MongoDB 4.0 dan versi lebih baru.

• Paksa Restart setelah Modifikasi Parameter: Tidak diperlukan.

• Nilai Default: 60.

• Fungsi: Menentukan siklus hidup transaksi. Unit: detik. Jika durasi eksekusi transaksi melebihi batas atas ini, transaksi ditandai sebagai kedaluwarsa dan dibatalkan oleh thread pembersihan periodik di latar belakang.

• Masalah: Klien Anda menerima kesalahan dalam format berikut:

  Pesan: "Membatalkan transaksi dengan txnNumber xxx pada sesi dengan lsid xxxxxxxxxx karena telah berjalan lebih lama dari 'transactionLifetimeLimitSeconds'"

• Saran Optimasi: Kurangi nilai parameter ini. Sebagai contoh, Anda dapat menurunkan nilai parameter menjadi 30. Kami merekomendasikan agar Anda tidak meningkatkan nilai parameter ini. Transaksi panjang yang belum dikomit dapat memberikan beban kerja berlebih pada cache WiredTiger. Jika cache kelebihan beban, banyak masalah terjadi, seperti database macet, peningkatan signifikan dalam latensi respons, dan pemanfaatan CPU tinggi. Ini mengakibatkan kerusakan bisnis. Hindari transaksi panjang dalam semua skenario. Untuk memperbaiki masalah timeout, bagi transaksi menjadi bagian-bagian yang lebih kecil sehingga transaksi dapat diselesaikan dalam periode waktu tertentu. Pastikan pernyataan query dioptimalkan dan berikan cakupan indeks yang sesuai untuk memastikan akses data cepat dalam transaksi.

Untuk informasi lebih lanjut tentang praktik terbaik untuk menggunakan transaksi, lihat Transaksi dan Read/Write Concern.

storage.oplogMinRetentionHours

• Versi Utama yang Didukung: MongoDB 4.4 dan versi lebih baru.

• Paksa Restart setelah Modifikasi Parameter: Tidak diperlukan.

• Nilai Default: 0, yang menunjukkan bahwa parameter ini tidak berlaku dan ukuran oplog ditentukan oleh parameter replication.oplogSizeMB.

• Fungsi: Menentukan periode retensi minimum dari koleksi oplog yang menyimpan log sinkronisasi logis.

• Masalah:

  • Jika parameter ini disetel terlalu besar, koleksi oplog menempati sejumlah besar ruang disk.

  • Beberapa pengguna mungkin lupa menentukan parameter ini dan kemudian bingung dengan fluktuasi ukuran disk.

• Saran Optimasi: Jika beban kerja Anda stabil, kami merekomendasikan agar Anda mempertahankan nilai default dari parameter ini. Jika operasi tulis Anda mengalami perubahan signifikan, kami merekomendasikan agar Anda menyetel parameter ini ke angka floating point lebih besar dari 1.0. Saat Anda mengonfigurasi parameter ini, evaluasi ruang disk yang dapat ditempati untuk menghindari skenario di mana instance Anda terkunci karena ruang disk habis.

storage.wiredTiger.collectionConfig.blockCompressor

• Versi Utama yang Didukung: MongoDB 3.0 dan versi lebih baru.

• Paksa Restart setelah Modifikasi Parameter: Diperlukan.

• Nilai Default: snappy.

• Fungsi: Menentukan algoritma kompresi penyimpanan default untuk data koleksi. Jika Anda mengubah algoritma kompresi penyimpanan default, hanya semua koleksi baru yang menggunakan algoritma baru yang ditentukan. Koleksi yang ada tidak terpengaruh. Anda dapat menyetel parameter ini ke none, snappy, zlib, atau zstd. Nilai zstd hanya tersedia untuk instance yang menjalankan MongoDB 4.2 dan versi lebih baru.

• Saran Optimasi: Ubah nilai parameter berdasarkan kebutuhan bisnis Anda. Algoritma kompresi yang berbeda memiliki karakteristik performa yang berbeda. Beberapa algoritma kompresi memberikan tingkat kompresi tinggi tetapi membawa overhead CPU tinggi karena kompresi dan dekompresi. Referensi hasil tes yang sesuai untuk memahami performa aktual dari algoritma kompresi yang berbeda. Jika instance Anda terutama menyimpan data dingin, Anda dapat mengubah nilai parameter menjadi zstd untuk mencapai rasio kompresi yang lebih tinggi.

  Catatan

  Jika Anda ingin menggunakan algoritma kompresi yang berbeda untuk koleksi yang berbeda, gunakan perintah eksplisit createCollection yang menyediakan opsi relevan. Untuk informasi lebih lanjut, lihat Specify Storage Engine Options.

setParameter.minSnapshotHistoryWindowInSeconds/setParameter.maxTargetSnapshotHistoryWindowInSeconds

• Versi Utama yang Didukung: MongoDB 4.4 dan versi lebih baru.

• Paksa Restart setelah Modifikasi Parameter: Tidak diperlukan.

• Nilai Default: 300. Unit: detik. Nilai default sama dengan 5 menit.

• Fungsi: Menentukan jendela selama snapshot di WiredTiger dipertahankan. Nilai 0 menunjukkan bahwa jendela ditutup. Parameter ini mendukung pembacaan data pada titik waktu yang ditentukan oleh parameter atClusterTime. Untuk informasi lebih lanjut, lihat Read Concern and atClusterTime.

• Masalah: Parameter ini memberikan beberapa beban kerja pada cache WiredTiger, terutama ketika sebuah dokumen sering diperbarui.

• Saran Optimasi: Tidak perlu menyesuaikan nilai parameter ini dalam sebagian besar kasus.

  • Jika Anda tidak ingin menggunakan fitur membaca atClusterTime, Anda dapat mengatur parameter ini ke 0 untuk peningkatan performa.

  • Jika Anda ingin membaca snapshot yang dihasilkan lebih dari 5 menit yang lalu, Anda dapat mengatur parameter ini ke nilai yang lebih besar. Namun, Anda juga perlu memperhatikan konsumsi memori tambahan dan overhead performa yang disebabkan oleh peningkatan nilai parameter ini.

  Catatan

  Jika Anda mengatur parameter ini ke nilai yang kecil dan menentukan titik waktu yang lebih awal untuk membaca snapshot, Anda akan menerima kesalahan SnapshotTooOld.

  rsconf.chainingAllowed

  • Versi Utama yang Didukung: MongoDB 4.0 dan versi selanjutnya.

  • Restart Paksa setelah Modifikasi Parameter: Tidak diperlukan.

  • Nilai Default: true.

  • Fungsi: Menentukan apakah akan mengizinkan replikasi berantai untuk instance replika set.

  • Masalah:

    • Jika replikasi berantai dinonaktifkan untuk instance replika set, node primer dalam instance tersebut mungkin memiliki beban yang lebih tinggi, seperti pemanfaatan CPU yang lebih tinggi dan lalu lintas jaringan.

    • Jika replikasi berantai diaktifkan untuk instance replika set, kemungkinan besar terjadi keterlambatan data pada node sekunder dari instance tersebut.

• Saran Optimasi:

  • Jika instance set replika berisi maksimal empat node, Anda dapat mengaktifkan atau menonaktifkan replikasi berantai untuk instance tersebut berdasarkan kebutuhan bisnis Anda.

  • Jika instance set replika berisi setidaknya lima node dan writeConcern dari instance disetel ke {w:majority}, Anda harus menyeimbangkan beban node utama dan performa instance. Jika Anda menonaktifkan replikasi berantai, performa tulis instance meningkat. Namun, beban node utama meningkat secara signifikan.

setParameter.migrateCloneInsertionBatchSize

• Versi Utama yang Didukung: MongoDB 4.0 dan versi lebih baru.

• Restart Paksa setelah Modifikasi Parameter: Tidak diperlukan.

• Nilai Default: 0, yang menunjukkan bahwa batch dapat berisi hingga 16 MB dokumen.

• Fungsi: Menentukan jumlah maksimum dokumen yang akan dimasukkan dalam satu batch selama tahap kloning proses migrasi chunk.

• Masalah: Fluktuasi performa terjadi pada shard selama proses migrasi chunk di beberapa skenario.

• Saran Optimasi: Tidak perlu menyesuaikan nilai parameter ini dalam kebanyakan kasus. Jika fluktuasi performa muncul di instans kluster sharded Anda selama penyeimbangan beban karena migrasi chunk, sesuaikan nilai parameter ini ke ukuran batch tetap.

setParameter.rangeDeleterBatchDelayMS

• Versi Utama yang Didukung: MongoDB 4.0 dan versi lebih baru.

• Restart Paksa setelah Modifikasi Parameter: Tidak diperlukan.

• Nilai Default: 20.

• Fungsi: Menentukan interval waktu sebelum batch penghapusan berikutnya selama tahap pembersihan proses migrasi chunk. Unit: milidetik. Parameter ini memengaruhi perintah cleanupOrphaned yang digunakan untuk membersihkan dokumen yatim piatu.

• Masalah:

  • Dalam beberapa skenario, pemanfaatan CPU dapat melonjak karena penghapusan dokumen secara asinkron setelah migrasi chunk.

  • Jika parameter ini disetel ke nilai yang terlalu besar, dokumen mungkin menjadi yatim piatu karena tidak dihapus tepat waktu. Selain itu, pesan kesalahan berikut mungkin muncul karena operasi penghapusan sejumlah besar dokumen mengalami timeout:

    Pesan: "OperationFailed: Data transfer error: ExceededTimeLimit: Failed to delete orphaned <db>.<collection> range [xxxxxx,xxxxx] :: caused by :: operation exceeded time limit"

• Saran Optimasi: Tidak perlu menyesuaikan nilai parameter ini dalam kebanyakan kasus. Jika pemanfaatan CPU instans kluster sharded Anda melonjak karena penghapusan dokumen secara asinkron selama penyeimbangan beban, Anda dapat meningkatkan nilai parameter tersebut. Misalnya, tingkatkan nilai parameter menjadi 200.

setParameter.rangeDeleterBatchSize

• Versi Utama yang Didukung: MongoDB 4.0 dan versi lebih baru.

• Restart Paksa setelah Modifikasi Parameter: Tidak diperlukan.

• Nilai Default: 0, yang menunjukkan bahwa sistem menggunakan nilai yang sesuai. Dalam kebanyakan kasus, nilainya adalah 128.

• Fungsi: Menentukan jumlah maksimum dokumen dalam satu batch penghapusan asinkron selama tahap pembersihan proses migrasi chunk.

• Masalah: Pemanfaatan CPU dapat melonjak karena penghapusan dokumen secara asinkron setelah migrasi chunk di beberapa skenario.

• Saran Optimasi: Tidak perlu menyesuaikan nilai parameter ini dalam kebanyakan kasus. Jika pemanfaatan CPU instans kluster sharded Anda melonjak karena penghapusan dokumen secara asinkron selama penyeimbangan beban, sesuaikan nilai parameter ini ke ukuran batch tetap.

setParameter.chunkMigrationConcurrency

• Versi Utama yang Didukung: MongoDB 5.0 dan 7.0.

• Restart Paksa setelah Modifikasi Parameter: Tidak diperlukan.

• Nilai Default: 1.

• Fungsi: Menentukan jumlah thread konkuren yang digunakan untuk memigrasi chunk.

• Masalah: Chunk mungkin dipindahkan dengan lambat oleh balancer dan percepatan diperlukan di beberapa skenario, seperti saat shard ditambahkan atau dihapus.

• Saran Optimasi: Tidak perlu menyesuaikan nilai parameter ini dalam kebanyakan kasus. Jika Anda ingin mempercepat proses penyeimbangan, Anda dapat meningkatkan nilai parameter tersebut. Setelah penyesuaian, Anda harus memperhatikan beban instans Anda dan dampaknya terhadap bisnis Anda. Jika masalah terjadi, Anda harus mengembalikan nilai parameter tersebut secara tepat waktu.

setParameter.receiveChunkWaitForRangeDeleterTimeoutMS

• Versi Utama yang Didukung: MongoDB 4.4 dan versi lebih baru.

• Restart Paksa setelah Modifikasi Parameter: Tidak diperlukan.

• Nilai Default: 10000. Unit: milidetik. Nilai default sama dengan 10 detik.

• Fungsi: Menentukan periode timeout yang diperlukan untuk menunggu penghapusan dokumen yatim piatu sebelum migrasi chunk.

• Masalah: Saat balancer sedang berjalan, log berikut yang menunjukkan kesalahan timeout dihasilkan:

  ExceededTimeLimit: Failed to delete orphaned <db.collection> range [{ <shard_key>: MinKey }, { <shard_key>: -9186000910690368367 }) :: caused by :: operation exceeded time limit

• Saran Optimasi: Tidak perlu menyesuaikan nilai parameter ini dalam kebanyakan kasus. Jika kesalahan di atas terjadi, Anda dapat menyetel parameter ini ke nilai yang lebih besar. Dengan cara ini, operasi moveChunk dapat menunggu lebih lama untuk menghapus dokumen yatim piatu, yang menghindari kesalahan timeout serupa.

setParameter.minSnapshotHistoryWindowInSeconds/setParameter.maxTargetSnapshotHistoryWindowInSeconds

• Versi Utama yang Didukung: MongoDB 4.4 dan versi lebih baru.

• Restart Paksa setelah Modifikasi Parameter: Tidak diperlukan.

• Nilai Default: 300. Unit: detik. Nilai default sama dengan 5 menit.

• Fungsi: Menentukan jendela waktu selama snapshot di WiredTiger dipertahankan. Nilai 0 menunjukkan bahwa jendela ditutup. Parameter ini mendukung pembacaan data pada titik waktu tertentu yang ditentukan oleh parameter atClusterTime. Untuk informasi lebih lanjut, lihat Read Concern and atClusterTime.

• Masalah: Parameter ini memberikan beberapa beban pada cache WiredTiger, terutama ketika dokumen sering diperbarui.

• Saran Optimasi: Tidak perlu menyesuaikan nilai parameter ini dalam kebanyakan kasus.

  • Jika Anda tidak ingin menggunakan fitur read atClusterTime, Anda dapat menyetel parameter ini ke 0 untuk meningkatkan performa.

  • Jika Anda ingin membaca snapshot yang dihasilkan lebih dari 5 menit yang lalu, Anda dapat menyetel parameter ini ke nilai yang lebih besar. Namun, Anda juga perlu memperhatikan konsumsi memori tambahan dan overhead performa yang disebabkan oleh peningkatan nilai parameter tersebut.

  Catatan

  Jika Anda menyetel parameter ini ke nilai yang kecil dan menentukan titik waktu yang lebih awal untuk membaca snapshot, Anda akan menerima kesalahan SnapshotTooOld.

  rsconf.chainingAllowed

  • Versi Utama yang Didukung: MongoDB 4.0 dan versi lebih baru.

  • Restart Paksa setelah Modifikasi Parameter: Tidak diperlukan.

  • Nilai Default: true.

  • Fungsi: Menentukan apakah akan mengizinkan replikasi berantai untuk instance set replika.

  • Masalah:

    • Jika replikasi berantai dinonaktifkan untuk instans replica set, node primer dalam instans tersebut mungkin membawa beban yang lebih tinggi, seperti pemanfaatan CPU yang lebih tinggi dan lalu lintas jaringan.

    • Jika replikasi berantai diaktifkan untuk instans replica set, kemungkinan besar terjadi lag data pada node sekunder instans tersebut.

• Saran Optimasi:

  • Jika instans replica set berisi maksimal empat node, Anda dapat mengaktifkan atau menonaktifkan replikasi berantai untuk instans tersebut berdasarkan kebutuhan bisnis Anda.

  • Jika instans replica set berisi setidaknya lima node dan writeConcern instans tersebut disetel ke{w:majority}, Anda harus menyeimbangkan beban node primer dan performa instans. Jika Anda menonaktifkan replikasi berantai, performa tulis instans meningkat. Namun, beban node primer meningkat secara signifikan.

operationProfiling.slowOpThresholdMs

• Versi Utama yang Didukung: MongoDB 3.0 dan versi lebih baru.

• Paksa Restart Setelah Modifikasi Parameter: Tidak diperlukan.

• Nilai Default: 100.

• Fungsi: Menentukan ambang batas untuk mengidentifikasi query lambat.

• Masalah:

  • Jika parameter ini disetel terlalu kecil, sejumlah besar log query lambat dan log audit tambahan akan dihasilkan, memperpanjang waktu analisis query lambat.

  • Jika parameter ini disetel terlalu besar, banyak query lambat tidak akan dicatat dalam log, juga memperpanjang waktu analisis query lambat.

• Saran Optimasi: Sesuaikan nilai parameter berdasarkan kebutuhan bisnis Anda. Kami merekomendasikan menyetel parameter ini ke nilai lebih besar dari durasi rata-rata query utama bisnis Anda. Contoh:

  • Untuk bisnis dengan sensitivitas tinggi terhadap latensi query (durasi query harian sekitar 30 milidetik), turunkan nilai parameter menjadi 50 untuk memfasilitasi analisis query lambat dengan jitter sesaat.

  • Untuk bisnis dengan query analitik (durasi query harian antara 300 hingga 400 milidetik), tingkatkan nilai parameter menjadi 500 untuk mengurangi jumlah log query lambat yang dihasilkan.

setParameter.ShardingTaskExecutorPoolMaxConnecting

• Versi Utama yang Didukung: MongoDB 3.6 dan versi lebih baru.

• Paksa Restart Setelah Modifikasi Parameter:

  • Untuk MongoDB 3.6 dan MongoDB 4.0: Diperlukan.

  • Untuk MongoDB 4.2 dan versi lebih baru: Tidak diperlukan.

• Nilai Default: 2.

• Fungsi: Menentukan jumlah maksimum koneksi yang dapat dibuat dalam kumpulan koneksi TaskExecutor node mongos selama inisialisasi koneksi. Parameter ini memengaruhi kecepatan pembuatan koneksi antara mongos dan mongod.

• Masalah: Jika parameter ini disetel terlalu besar, pemanfaatan CPU pada node mongos dapat melonjak ketika banyak koneksi dibuat.

• Saran Optimasi: Kami merekomendasikan agar Anda tidak menyesuaikan nilai parameter ini.

setParameter.ShardingTaskExecutorPoolMaxSize

• Versi Utama yang Didukung: MongoDB 3.6 dan versi lebih baru.

• Paksa Restart Setelah Modifikasi Parameter:

  • Untuk MongoDB 3.6 dan MongoDB 4.0: Diperlukan.

  • Untuk MongoDB 4.2 dan versi lebih baru: Tidak diperlukan.

• Nilai Default: 2^64-1, yang menunjukkan nilai maksimum tipe data INT64.

• Fungsi: Menentukan jumlah maksimum koneksi dalam setiap kumpulan koneksi TaskExecutor node mongos.

• Saran Optimasi: Tidak perlu menyesuaikan nilai parameter ini. Konfigurasikan parameter untuk membatasi jumlah maksimum koneksi antara mongos dan shard. Hindari menyetel parameter ini ke nilai kecil karena dapat menyebabkan permintaan pada mongos terblokir saat semua koneksi habis.

setParameter.ShardingTaskExecutorPoolMinSize

• Versi Utama yang Didukung: MongoDB 3.6 dan versi lebih baru.

• Paksa Restart Setelah Modifikasi Parameter:

  • Untuk MongoDB 3.6 dan MongoDB 4.0: Diperlukan.

  • Untuk MongoDB 4.2 dan versi lebih baru: Tidak diperlukan.

• Nilai Default: 1.

• Fungsi: Menentukan jumlah minimum koneksi dalam setiap kumpulan koneksi TaskExecutor node mongos.

• Masalah: Dalam beberapa skenario, lonjakan permintaan pada mongos dapat menyebabkan penambahan koneksi pada kumpulan koneksi TaskExecutor, meningkatkan pemanfaatan CPU dan masalah lainnya.

• Saran Optimasi: Kami menyarankan Anda menyetel parameter ini ke nilai antara 10 hingga 50, bergantung pada jumlah shard dan jumlah node dalam setiap shard. Perlu diperhatikan bahwa overhead sumber daya yang rendah akan terjadi ketika mongos mempertahankan koneksi idle ke shard.

setParameter.cursorTimeoutMillis

• Versi Utama yang Didukung: MongoDB 3.0 dan versi lebih baru.

• Paksa Restart Setelah Modifikasi Parameter: Tidak diperlukan.

• Nilai Default: 600000, yang sama dengan 10 menit.

• Fungsi: Menentukan ambang kedaluwarsa cursor idle. Unit: milidetik. Jika waktu idle cursor melebihi ambang ini, ApsaraDB for MongoDB secara otomatis menghapus cursor.

• Masalah: Jika Anda mencoba mengakses cursor yang sudah kedaluwarsa dan dihapus, klien Anda akan menerima kesalahan dalam format berikut:

  Pesan: "cursor id xxxxxxx not found"
  KodeKesalahan: CursorNotFound(43)

• Saran Optimasi: Kami merekomendasikan agar Anda tidak meningkatkan nilai parameter ini. Untuk mengurangi overhead sumber daya dari cursor idle, kurangi nilai parameter ini. Sebagai contoh, Anda dapat menurunkan nilai parameter menjadi 300000. Hindari cursor idle untuk jangka waktu lama dalam semua skenario.