ApsaraDB for MongoDB：Rekomendasi penyetelan parameter

operationProfiling.mode

• Versi utama yang didukung: 3.0 dan seterusnya

• Perlu restart setelah modifikasi: Ya

• Nilai default: off

• Fungsi: Menentukan tingkat profiler kueri.

• Gejala:

  • Jika parameter ini diatur ke all atau slowOp dan banyak log kueri lambat dihasilkan, performa instans dapat menurun.

  • Beberapa pengguna mungkin lupa menonaktifkan profiler kueri dan menemukan koleksi system.profile di salah satu database mereka.

  • Beberapa pengguna mungkin keliru menganggap bahwa parameter ini harus diatur ke slowOp agar log kueri lambat dihasilkan.

• Rekomendasi:

  Pertahankan nilai default. Mengaktifkan profiler kueri dapat menurunkan performa instans, sedangkan log kueri lambat biasanya memberikan informasi serupa untuk analisis. Aktifkan profiler hanya bila diperlukan, dan segera nonaktifkan setelah analisis selesai. Untuk informasi lebih lanjut tentang Database Profiler, lihat dokumentasi resmi.

operationProfiling.slowOpThresholdMs

• Versi utama yang didukung: 3.0 dan seterusnya

• Perlu restart setelah modifikasi: Tidak

• Nilai default: 100

• Fungsi: Menentukan ambang batas untuk kueri lambat.

• Gejala:

  • Jika nilainya terlalu kecil, banyak log kueri lambat dan log audit dihasilkan. Hal ini menimbulkan kebisingan yang mempersulit analisis kueri lambat.

  • Jika nilainya terlalu besar, banyak kueri lambat tidak terekam dalam log. Hal ini mempersulit proses analisis kueri lambat.

• Rekomendasi: Sesuaikan ambang batas berdasarkan kebutuhan bisnis Anda. Atur parameter ini ke nilai yang sedikit lebih tinggi dari waktu eksekusi rata-rata kueri inti Anda. Contohnya:

  • Untuk bisnis yang sensitif terhadap latensi kueri dan memiliki waktu kueri tipikal sekitar 30 ms, Anda dapat menurunkan parameter ini menjadi 50 untuk membantu menganalisis jitter kueri lambat transien.

  • Untuk bisnis dengan kueri analitis berat dan waktu kueri tipikal 300 ms hingga 400 ms, Anda dapat menaikkan parameter ini menjadi 500 ms untuk mengurangi kebisingan log lambat.

replication.oplogGlobalIdEnabled

• Versi utama yang didukung: 4.0 dan seterusnya

• Perlu restart setelah modifikasi: Ya

• Nilai default: false

• Fungsi: Menentukan apakah akan mengaktifkan global ID (GID) dalam oplog untuk mendukung sinkronisasi dua arah dengan DTS atau mongoShake. Ini adalah parameter hasil pengembangan sendiri. GID digunakan untuk menyelesaikan masalah sinkronisasi melingkar dalam sinkronisasi dua arah.

• Rekomendasi: Aktifkan parameter ini hanya saat Anda memerlukan sinkronisasi dua arah. Perubahan ini memerlukan restart instans, jadi lakukan perubahan tersebut pada jam sepi.

replication.oplogSizeMB

• Versi utama yang didukung: 3.0 dan seterusnya

• Perlu restart setelah modifikasi: Tidak

• Nilai default: 10% dari disk space untuk tipe instans. Misalnya, jika instans memiliki disk space 500 GB, oplogSizeMB awal adalah 51200, yaitu 50 GB.

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

• Gejala: Jika nilai ini terlalu kecil, node secondary mungkin gagal mengimbangi dan masuk ke status RECOVERING. Backup log juga mungkin melewatkan catatan oplog, sehingga menimbulkan celah yang mencegah pemulihan berdasarkan titik waktu.

• Rekomendasi: Pertahankan nilai default. Jangan turunkan nilainya. Naikkan jika diperlukan. Pertimbangkan untuk menaikkan nilai ini jika workload Anda melibatkan volume data kecil tetapi pembaruan yang sering, yang menghasilkan entri oplog dengan cepat. Nilai `oplogSizeMB` yang lebih besar memungkinkan oplog mencakup periode yang lebih lama, sehingga mencegah celah dalam catatan oplog. Sebagai praktik terbaik, atur ukuran oplog agar menyimpan catatan oplog minimal selama satu jam.

setParameter.cursorTimeoutMillis

• Versi utama yang didukung: 3.0 dan seterusnya

• Perlu restart setelah modifikasi: Tidak

• Nilai default: 600000 (10 menit)

• Fungsi: Ambang batas kedaluwarsa untuk cursor yang idle, dalam milidetik. Jika cursor idle lebih lama dari ambang batas ini, MongoDB secara otomatis membersihkannya.

• Gejala: Jika Anda mencoba mengakses cursor yang telah dibersihkan, client menerima error dalam format berikut:

  Message: "cursor id xxxxxxx not found"
  ErrorCode: CursorNotFound(43)

• Rekomendasi: Jangan naikkan nilai ini. Untuk mengurangi overhead resource dari cursor idle, Anda dapat menurunkan nilainya, misalnya menjadi 300000. Dalam semua skenario, hindari penggunaan cursor yang idle lama di sisi bisnis.

setParameter.flowControlTargetLagSeconds

• Versi utama yang didukung: 4.2 dan seterusnya

• Perlu restart setelah modifikasi: Tidak

• Nilai default: 10

• Fungsi: Ambang batas yang memicu mekanisme flow control. Flow control memastikan bahwa sebagian besar commit point tidak tertinggal terlalu jauh.

• Gejala: Muncul log kueri lambat seperti berikut. Permintaan terpengaruh secara signifikan, dan waktu eksekusi meningkat drastis. Nilai `durationMillis` hampir sama dengan `flowControl.timeAcquiringMicros`, yang menunjukkan bahwa permintaan lambat terutama dipengaruhi oleh flow control.

  {
    "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
    }
  }
  

• Rekomendasi: Anda dapat menaikkan parameter ini untuk mengurangi sensitivitas mekanisme flow control. Jika permintaan masih sering dikendalikan alirannya setelah Anda menaikkan nilai, instans mengalami bottleneck performa dalam sinkronisasi primary-secondary. Anda harus menganalisis masalah ini lebih lanjut dan mengambil tindakan lain untuk menyelesaikannya, seperti meningkatkan konfigurasi instans atau mengatur write concern ke majority.

setParameter.oplogFetcherUsesExhaust

• Versi utama yang didukung: 4.4 dan seterusnya

• Perlu restart setelah modifikasi: Ya

• Nilai default: true

• Fungsi: Menentukan apakah akan mengaktifkan Stream Replication. Jika fitur ini dinonaktifkan, sinkronisasi primary-secondary kembali ke metode pull yang digunakan pada versi sebelumnya. Dalam metode ini, node secondary mengirim permintaan ke sumber sinkronisasi untuk mengambil batch entri oplog, lalu menunggu balasan. Artinya, setiap batch entri oplog memerlukan satu round trip jaringan.

• Gejala: Dalam beberapa skenario, mekanisme stream replication dapat menyebabkan overhead performa dan lebar pita jaringan tambahan.

• Rekomendasi: Jangan sesuaikan parameter ini. Stream replication dapat mengurangi latensi replikasi di lingkungan jaringan dengan beban tinggi dan latensi tinggi. Fitur ini juga dapat mengurangi risiko kehilangan data dari write jika node primary dengan write concern {w:1} mati secara tak terduga. Selain itu, fitur ini dapat mengurangi latensi write untuk write concern lain yang bergantung pada replikasi primary-secondary, seperti {w:majority} atau {w:>1}.

setParameter.maxTransactionLockRequestTimeoutMillis

• Versi utama yang didukung: 4.0 dan seterusnya

• Perlu restart setelah modifikasi: Tidak

• Nilai default: 5

• Fungsi: Menentukan timeout untuk transaksi dalam mengakuisisi lock, dalam milidetik. Jika operasi dalam transaksi tidak dapat mengakuisisi lock yang diperlukan dalam waktu yang ditentukan, transaksi tersebut secara otomatis dibatalkan.

• Gejala: Pesan error timeout lock seperti berikut muncul di log atau di client. Driver yang lebih baru secara otomatis mencoba ulang pada TransientTransactionError, sehingga error mungkin hanya muncul di log dan tidak terlihat oleh client.

  Message: "Unable to acquire lock '{8442595743001781021: Database, 1525066715360699165}' within a max lock request timeout of '5ms' milliseconds."
  ErrorCode: LockTimeout(24)

• Rekomendasi: Jika client sering mengalami error serupa, Anda dapat mencoba menaikkan parameter ini. Hal ini dapat membantu mengurangi pembatalan transaksi akibat ketidakmampuan mengakuisisi lock konkuren. Namun, hal ini juga menunda pembatalan operasi transaksi yang deadlock. Jika masalah tetap berlanjut setelah Anda menaikkan parameter, jangan naikkan lagi. Sebaliknya, optimalkan logika bisnis Anda. Misalnya, hindari modifikasi konkuren pada dokumen yang sama dalam transaksi. Tinjau juga operasi dalam transaksi untuk memeriksa adanya operasi yang mungkin menahan lock dalam waktu lama, seperti Data Definition Language (DDL) atau kueri yang tidak dioptimalkan. Hal ini membantu mencegah masalah serupa sejak awal.

setParameter.replWriterThreadCount

• Versi utama yang didukung: 3.2 dan seterusnya

• Perlu restart setelah modifikasi: Ya

• Nilai default: 16

• Fungsi: Menentukan jumlah maksimum thread untuk replikasi paralel selama sinkronisasi primary-secondary. Jumlah maksimum thread efektif adalah dua kali jumlah core CPU dari tipe instans.

• Gejala: Dalam skenario ekstrem, sinkronisasi primary-secondary mungkin tertunda, menyebabkan latensi replikasi (lag) pada node secondary terus meningkat.

• Rekomendasi: Dalam kebanyakan kasus, jangan sesuaikan parameter ini. Dalam kasus khusus, sesuaikan berdasarkan rekomendasi insinyur Alibaba Cloud.

setParameter.tcmallocAggressiveMemoryDecommit

• Versi utama yang didukung: 4.2 dan seterusnya

• Perlu restart setelah modifikasi: Tidak

• Nilai default: 0 (Menonaktifkan aggressive decommit untuk TCMalloc)

• Fungsi: MongoDB menggunakan TCMalloc sebagai alokator memorinya. Parameter ini mengontrol apakah akan mengaktifkan kebijakan aggressive decommit untuk TCMalloc. Saat diaktifkan, MongoDB secara aktif mencoba menggabungkan blok memori bebas yang berdekatan dan mengembalikan sebagian memori ke sistem operasi.

• Gejala:

  • Terjadi error kehabisan memori (OOM) pada node mongod karena memori tidak dapat diklaim cukup cepat untuk mengimbangi konsumsi memori tinggi dari kueri.

  • Saat instans berjalan, fragmentasi heap memory meningkat. Hal ini tampak sebagai penggunaan memori yang melebihi 80% dan naik perlahan namun terus-menerus.

• Rekomendasi: Dalam kebanyakan kasus, jangan sesuaikan parameter ini. Jika Anda mengalami masalah terkait memori, pertimbangkan untuk menyesuaikannya pada jam sepi.

setParameter.transactionLifetimeLimitSeconds

• Versi utama yang didukung: 4.0 dan seterusnya

• Perlu restart setelah modifikasi: Tidak

• Nilai default: 60

• Fungsi: Menentukan siklus hidup transaksi, dalam detik. Jika total waktu eksekusi transaksi melebihi batas ini, transaksi tersebut ditandai sebagai kedaluwarsa dan secara aktif dibatalkan oleh thread pembersihan latar belakang periodik.

• Gejala: Client mengalami error dalam format berikut:

  Message: "Aborting transaction with txnNumber xxx on session with lsid xxxxxxxxxx because it has been running for longer than 'transactionLifetimeLimitSeconds'"

• Rekomendasi: Anda dapat menurunkan nilai ini, misalnya menjadi 30. Jangan naikkan nilainya. Transaksi jangka panjang yang tidak dikomit dapat memberikan tekanan berat pada cache mesin penyimpanan WiredTiger. Cache yang kelebihan beban dapat menyebabkan lebih banyak masalah, seperti tersendatnya database, lonjakan besar pada latensi permintaan, dan pemanfaatan CPU penuh, yang dapat merugikan bisnis Anda. Hindari transaksi jangka panjang dalam semua skenario. Untuk mengatasi masalah timeout, pecah transaksi menjadi bagian-bagian kecil yang dapat selesai dalam batas waktu yang dikonfigurasi. Anda juga harus mengoptimalkan kueri Anda dan memastikan kueri tersebut memiliki cakupan indeks yang tepat untuk akses data cepat dalam transaksi.

Untuk informasi lebih lanjut tentang praktik terbaik penggunaan transaksi, lihat Transactions and Read/Write Concern.

storage.oplogMinRetentionHours

• Versi utama yang didukung: 4.4 dan seterusnya

• Perlu restart setelah modifikasi: Tidak

• Nilai default: 0 (Parameter ini dinonaktifkan. Ukuran oplog sepenuhnya dikontrol oleh parameter replication.oplogSizeMB.)

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

• Gejala:

  • Jika nilai ini terlalu besar, koleksi oplog menempati terlalu banyak disk space.

  • Beberapa pengguna lupa bahwa mereka telah mengatur parameter ini dan bingung oleh fluktuasi disk space instans.

• Rekomendasi: Untuk workload yang relatif stabil, pertahankan nilai default. Untuk workload yang mungkin mengalami perubahan besar dalam operasi write, atur parameter ini ke bilangan titik mengambang lebih besar dari 1.0. Saat mengatur parameter ini, evaluasi juga potensi penggunaan disk space untuk menghindari pemicuan lock disk penuh, yang dapat menyebabkan masalah lain.

storage.wiredTiger.collectionConfig.blockCompressor

• Versi utama yang didukung: 3.0 dan seterusnya

• Perlu restart setelah modifikasi: Ya

• Nilai default: snappy

• Fungsi: Mengatur algoritma kompresi penyimpanan untuk data koleksi. Perubahan ini hanya berlaku untuk koleksi baru. Koleksi yang sudah ada tidak terpengaruh. Algoritma yang didukung meliputi none (tanpa kompresi), snappy, zlib, dan zstd. Algoritma zstd hanya didukung di MongoDB 4.2 dan seterusnya.

• Rekomendasi: Modifikasi parameter ini sesuai kebutuhan. Algoritma kompresi berbeda memiliki karakteristik performa berbeda. Beberapa menawarkan rasio kompresi lebih tinggi tetapi memiliki overhead CPU lebih besar untuk kompresi dan dekompresi. Perbandingan aktual antar algoritma kompresi harus didasarkan pada hasil pengujian Anda sendiri. Jika instans terutama digunakan untuk menyimpan data dingin, pertimbangkan mengubah parameter ini menjadi zstd untuk mencapai rasio kompresi lebih tinggi.

  Catatan

  Jika Anda ingin menggunakan algoritma kompresi berbeda untuk koleksi berbeda, gunakan perintah eksplisit createCollection dengan opsi terkait. Untuk informasi lebih lanjut, lihat dokumentasi resmi MongoDB.

setParameter.minSnapshotHistoryWindowInSeconds/setParameter.maxTargetSnapshotHistoryWindowInSeconds

• Versi utama yang didukung: 4.4 dan seterusnya

• Perlu restart setelah modifikasi: Tidak

• Nilai default: 300 (5 menit)

• Fungsi: Ukuran jendela selama mesin WiredTiger menyimpan riwayat snapshot. Satuannya adalah detik. Nilai 0 menonaktifkan jendela riwayat snapshot. Parameter ini terutama digunakan untuk mendukung pembacaan menggunakan atClusterTime.

• Gejala: Parameter ini dapat menambah tekanan pada cache WiredTiger (WT cache), terutama dalam skenario di mana dokumen yang sama sering diperbarui.

• Rekomendasi: Dalam kebanyakan kasus, tidak perlu penyesuaian.

  • Jika bisnis Anda tidak menggunakan fitur pembacaan snapshot historis (read atClusterTime), Anda dapat mengatur parameter ini ke 0 untuk mendapatkan peningkatan performa.

  • Jika bisnis Anda perlu membaca data snapshot dari lebih dari 5 menit yang lalu, Anda dapat menaikkan parameter ini. Namun, waspadai konsumsi memori tambahan dan overhead performa yang mungkin ditimbulkan.

  Catatan

  Jika nilai parameter ini kecil dan Anda menentukan waktu yang lebih awal saat membaca snapshot historis, error SnapshotTooOld akan dikembalikan.

rsconf.chainingAllowed

• Versi utama yang didukung: 4.0 dan seterusnya

• Perlu restart setelah modifikasi: Tidak

• Nilai default: true

• Fungsi: Menentukan apakah akan mengizinkan replikasi berantai dalam replica set.

• Gejala:

  • Menonaktifkan replikasi berantai dapat meningkatkan beban pada node primary, misalnya pemanfaatan CPU dan network traffic.

  • Mengaktifkan replikasi berantai dapat membuat node secondary lebih mudah tertinggal dalam replikasi data.

• Rekomendasi:

  • Untuk empat node atau kurang: Aktifkan atau nonaktifkan replikasi berantai sesuai kebutuhan.

  • Untuk lima node atau lebih: Jika write concern diatur ke {w:majority}, Anda harus mempertimbangkan trade-off antara beban node primary dan performa instans. Menonaktifkan replikasi berantai meningkatkan performa write, tetapi juga secara signifikan meningkatkan beban pada node primary.

setParameter.internalQueryMaxPushBytes/setParameter.internalQueryMaxAddToSetBytes

• Versi utama yang didukung: 4.2 dan seterusnya

• Perlu restart setelah modifikasi: Tidak

• Nilai default: 104857600 B (100 MB)

• Fungsi: Membatasi memori maksimum yang dapat digunakan oleh operator $push dan $addToSet.

• Gejala: Kueri tertentu yang berisi $push atau $addToSet gagal dan mengembalikan pesan error seperti berikut.

  "errMsg": "$push used too much memory and cannot spill to disk. Memory limit: 104857600... 

• Rekomendasi: Dalam kebanyakan kasus, tidak perlu penyesuaian. Jika Anda mengalami error ini saat menjalankan kueri tertentu, Anda dapat menaikkan nilainya. Perhatikan bahwa jika Anda mengatur parameter ini ke nilai yang sangat besar, error kehabisan memori (OOM) dapat terjadi pada node mongod.

setParameter.migrateCloneInsertionBatchSize

• Versi utama yang didukung: 4.0 dan seterusnya

• Perlu restart setelah modifikasi: Tidak

• Nilai default: 0 (Dibatasi oleh batas ukuran dokumen 16 MB)

• Fungsi: Menentukan jumlah maksimum dokumen dalam satu batch selama langkah clone migrasi chunk.

• Gejala: Dalam beberapa skenario, migrasi chunk dapat menyebabkan fluktuasi performa pada shard.

• Rekomendasi: Dalam kebanyakan kasus, tidak perlu penyesuaian. Jika instansi kluster sharded Anda mengalami fluktuasi performa akibat migrasi chunk selama balancing, pertimbangkan untuk menyesuaikan parameter ini ke ukuran batch tetap.

setParameter.rangeDeleterBatchDelayMS

• Versi utama yang didukung: 4.0 dan seterusnya

• Perlu restart setelah modifikasi: Tidak

• Nilai default: 20

• Fungsi: Interval antara penghapusan batch selama langkah pembersihan migrasi chunk. Ini juga memengaruhi perintah cleanupOrphaned, yang membersihkan dokumen orphaned. Satuannya adalah milidetik.

• Gejala:

  • Dalam beberapa skenario, penghapusan dokumen asinkron setelah migrasi chunk dapat menyebabkan lonjakan CPU.

  • Jika nilainya terlalu besar, dokumen mungkin tidak dihapus tepat waktu dan menjadi orphaned. Atau, jika terlalu banyak dokumen perlu dihapus, dapat terjadi timeout, menghasilkan log error berikut:

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

• Rekomendasi: Dalam kebanyakan kasus, tidak perlu penyesuaian. Jika pemanfaatan CPU instansi kluster sharded Anda melonjak akibat penghapusan dokumen asinkron selama balancing, pertimbangkan untuk menaikkan parameter ini, misalnya menjadi 200.

setParameter.rangeDeleterBatchSize

• Versi utama yang didukung: 4.0 dan seterusnya

• Perlu restart setelah modifikasi: Tidak

• Nilai default: 0 (Secara otomatis memilih ukuran batch yang wajar, biasanya 128)

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

• Gejala: Dalam beberapa skenario, penghapusan dokumen asinkron setelah migrasi chunk dapat menyebabkan lonjakan pemanfaatan CPU.

• Rekomendasi: Dalam kebanyakan kasus, tidak perlu penyesuaian. Jika pemanfaatan CPU instansi kluster sharded Anda melonjak akibat penghapusan dokumen asinkron selama balancing, pertimbangkan untuk menyesuaikan parameter ini ke ukuran batch tetap.

setParameter.receiveChunkWaitForRangeDeleterTimeoutMS

• Versi utama yang didukung: 4.4 dan seterusnya

• Perlu restart setelah modifikasi: Tidak

• Nilai default: 10000 (10 detik)

• Fungsi: Menentukan timeout untuk menunggu penghapusan dokumen orphaned sebelum migrasi chunk, dalam milidetik.

• Gejala: Saat balancer berjalan, Anda mungkin melihat log error timeout berikut:

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

• Rekomendasi: Dalam kebanyakan kasus, tidak perlu penyesuaian. Jika Anda mengalami error tersebut, Anda dapat menaikkan parameter ini. Hal ini memungkinkan operasi moveChunk menunggu lebih lama agar penghapusan dokumen orphaned selesai, yang membantu menghindari error timeout serupa.

setParameter.minSnapshotHistoryWindowInSeconds/setParameter.maxTargetSnapshotHistoryWindowInSeconds

• Versi utama yang didukung: 4.4 dan seterusnya

• Perlu restart setelah modifikasi: Tidak

• Nilai default: 300 (5 menit)

• Fungsi: Ukuran jendela selama mesin WiredTiger menyimpan riwayat snapshot. Satuannya adalah detik. Nilai 0 menonaktifkan jendela riwayat snapshot. Parameter ini terutama digunakan untuk mendukung pembacaan menggunakan atClusterTime.

• Gejala: Parameter ini dapat menambah tekanan pada cache WiredTiger (WT cache), terutama dalam skenario di mana dokumen yang sama sering diperbarui.

• Rekomendasi: Dalam kebanyakan kasus, tidak perlu penyesuaian.

  • Jika bisnis Anda tidak menggunakan fitur pembacaan snapshot historis (read atClusterTime), Anda dapat mengatur parameter ini ke 0 untuk mendapatkan peningkatan performa.

  • Jika bisnis Anda perlu membaca data snapshot dari lebih dari 5 menit yang lalu, Anda dapat menaikkan parameter ini. Namun, waspadai konsumsi memori tambahan dan overhead performa yang mungkin ditimbulkan.

  Catatan

  Jika nilai parameter ini kecil dan Anda menentukan waktu yang lebih awal saat membaca snapshot historis, error SnapshotTooOld akan dikembalikan.

rsconf.chainingAllowed

• Versi utama yang didukung: 4.0 dan seterusnya

• Perlu restart setelah modifikasi: Tidak

• Nilai default: true

• Fungsi: Menentukan apakah akan mengizinkan replikasi berantai dalam shard.

• Gejala:

  • Menonaktifkan replikasi berantai dapat meningkatkan beban pada node primary, misalnya pemanfaatan CPU dan network traffic.

  • Mengaktifkan replikasi berantai dapat membuat node secondary lebih mudah tertinggal dalam replikasi data.

• Rekomendasi:

  • Untuk empat node atau kurang: Aktifkan atau nonaktifkan replikasi berantai sesuai kebutuhan.

  • Untuk lima node atau lebih: Jika write concern diatur ke {w:majority}, Anda harus mempertimbangkan trade-off antara beban node primary dan performa instans. Menonaktifkan replikasi berantai meningkatkan performa write, tetapi juga secara signifikan meningkatkan beban pada node primary.

setParameter.internalQueryMaxPushBytes/setParameter.internalQueryMaxAddToSetBytes

• Versi utama yang didukung: 4.2 dan seterusnya

• Perlu restart setelah modifikasi: Tidak

• Nilai default: 104857600 B (100 MB)

• Fungsi: Membatasi memori maksimum yang dapat digunakan oleh operator $push dan $addToSet.

• Gejala: Kueri tertentu yang berisi $push atau $addToSet gagal dan mengembalikan pesan error seperti berikut.

  "errMsg": "$push used too much memory and cannot spill to disk. Memory limit: 104857600... 

• Rekomendasi: Dalam kebanyakan kasus, tidak perlu penyesuaian. Jika Anda mengalami error ini saat menjalankan kueri tertentu, Anda dapat menaikkan nilainya. Perhatikan bahwa jika Anda mengatur parameter ini ke nilai yang sangat besar, error kehabisan memori (OOM) dapat terjadi pada node mongod.

operationProfiling.slowOpThresholdMs

• Versi utama yang didukung: 3.0 dan seterusnya

• Perlu restart setelah modifikasi: Tidak

• Nilai default: 100

• Fungsi: Menentukan ambang batas untuk kueri lambat.

• Gejala:

  • Jika nilainya terlalu kecil, banyak log kueri lambat dan log audit dihasilkan. Hal ini menimbulkan kebisingan yang mempersulit analisis kueri lambat.

  • Jika nilainya terlalu besar, banyak kueri lambat tidak terekam dalam log. Hal ini mempersulit proses analisis kueri lambat.

• Rekomendasi: Sesuaikan ambang batas berdasarkan kebutuhan bisnis Anda. Atur parameter ini ke nilai yang sedikit lebih tinggi dari waktu eksekusi rata-rata kueri inti Anda. Contohnya:

  • Untuk bisnis yang sensitif terhadap latensi kueri dan memiliki waktu kueri tipikal sekitar 30 ms, Anda dapat menurunkan parameter ini menjadi 50 untuk membantu menganalisis jitter kueri lambat transien.

  • Untuk bisnis dengan kueri analitis berat dan waktu kueri tipikal 300 ms hingga 400 ms, Anda dapat menaikkan parameter ini menjadi 500 ms untuk mengurangi kebisingan log lambat.

setParameter.ShardingTaskExecutorPoolMaxConnecting

• Versi utama yang didukung: 3.6 dan seterusnya

• Perlu restart setelah modifikasi:

  • Untuk 3.6 dan 4.0: Ya

  • Untuk 4.2 dan seterusnya: Tidak

• Nilai default: 2

• Fungsi: Menentukan konkurensi maksimum untuk inisialisasi koneksi dalam kolam koneksi TaskExecutor pada node Mongos instansi kluster sharded. Ini mengontrol kecepatan pembentukan koneksi dari Mongos ke mongod.

• Gejala: Jika nilai ini besar, pemanfaatan CPU node Mongos dapat melonjak saat banyak koneksi dibuat.

• Rekomendasi: Jangan sesuaikan parameter ini.

setParameter.ShardingTaskExecutorPoolMaxSize

• Versi utama yang didukung: 3.6 dan seterusnya

• Perlu restart setelah modifikasi:

  • Untuk 3.6 dan 4.0: Ya

  • Untuk 4.2 dan seterusnya: Tidak

• Nilai default: 2^64-1 (nilai maksimum untuk integer 64-bit)

• Fungsi: Menentukan jumlah maksimum koneksi dalam setiap kolam koneksi TaskExecutor pada node Mongos instansi kluster sharded.

• Rekomendasi: Tidak perlu penyesuaian. Anda dapat mengatur parameter ini untuk membatasi batas atas kolam koneksi dari Mongos ke shard. Namun, jangan atur ke nilai yang sangat kecil. Jika tidak, permintaan pada Mongos dapat diblokir saat kolam koneksi habis.

setParameter.ShardingTaskExecutorPoolMinSize

• Versi utama yang didukung: 3.6 dan seterusnya

• Perlu restart setelah modifikasi:

  • Untuk 3.6 dan 4.0: Ya

  • Untuk 4.2 dan seterusnya: Tidak

• Nilai default: 1

• Fungsi: Menentukan jumlah minimum koneksi dalam setiap kolam koneksi TaskExecutor pada node Mongos instansi kluster sharded.

• Gejala: Dalam beberapa skenario, lonjakan permintaan pada Mongos dapat menyebabkan kolam koneksi TaskExecutor membuat banyak koneksi baru. Hal ini dapat menyebabkan lonjakan CPU dan masalah lain pada node Mongos.

• Rekomendasi: Atur ke nilai yang wajar dalam rentang [10,50]. Nilai spesifik tergantung pada topologi kluster sharded Anda, seperti jumlah shard dan jumlah node dalam setiap shard. Perhatikan bahwa Mongos memiliki overhead resource kecil untuk memelihara koneksi idle ini ke shard.

setParameter.cursorTimeoutMillis

• Versi utama yang didukung: 3.0 dan seterusnya

• Perlu restart setelah modifikasi: Tidak

• Nilai default: 600000 (10 menit)

• Fungsi: Ambang batas kedaluwarsa untuk cursor yang idle, dalam milidetik. Jika cursor idle lebih lama dari ambang batas ini, MongoDB secara otomatis membersihkannya.

• Gejala: Jika Anda mencoba mengakses cursor yang telah dibersihkan, client menerima error dalam format berikut:

  Message: "cursor id xxxxxxx not found"
  ErrorCode: CursorNotFound(43)

• Rekomendasi: Jangan naikkan nilai ini. Untuk mengurangi overhead resource dari cursor idle, Anda dapat menurunkan nilainya, misalnya menjadi 300000. Dalam semua skenario, hindari penggunaan cursor yang idle lama di sisi bisnis.