ApsaraDB for MongoDB：參數調優建議

operationProfiling.mode

• 適用大版本：大於等於3.0

• 修改完是否需要重啟：是

• 預設值：off

• 作用：指定查詢分析器的層級。

• 現象：

  • 如果設定為all或者slowOp且慢日誌比較多時，可能會出現執行個體效能退化而引起困惑。

  • 部分客戶也會因為忘了關閉查詢分析器而對自己的某個庫裡出現system.profile集合而感到困惑。

  • 部分客戶也會誤解以為需要將此參數設定為slowOp才會產生慢日誌。

• 修改建議：

  維持預設值。不僅僅由於開啟查詢分析器會帶來一定的執行個體效能退化，而且慢日誌一般也能提供類似的分析資訊。請在必要的時候才考慮開啟，並且在開啟且分析完畢後及時關閉。更多關於查詢分析器（Database Profiler）的資訊，請參見官方文檔。

operationProfiling.slowOpThresholdMs

• 適用大版本：大於等於3.0

• 修改完是否需要重啟：否

• 預設值：100

• 作用：定義一個查詢是否為慢查詢的閾值。

• 現象：

  • 參數設定過小，將導致產生大量慢日誌和審計日誌，帶來慢日誌噪音影響慢查詢分析。

  • 參數設定過大，將導致很多慢查詢並不輸出在日誌中，影響慢查詢分析過程。

• 修改建議：根據業務的實際情況適當調小或調大閾值，推薦設定為比業務核心查詢的平均耗時稍大些的值。樣本如下：

  • 假設一個對查詢延時比較敏感的業務，日常的查詢耗時都僅在30ms左右，為了協助分析一些瞬時抖動的慢查詢情況，可以將此參數調小到50。

  • 假設一個分析查詢比較重的業務，日常查詢耗時都在300~400ms左右，為了減少慢日誌噪音，可以將此參數調大到500ms。

replication.oplogGlobalIdEnabled

• 適用大版本：大於等於4.0

• 修改完是否需要重啟：是

• 預設值：false

• 作用：是否開啟oplog的GID來支援DTS或mongoShake的雙向同步，該參數為自研參數。GID的目的是為瞭解決雙向同步中的環形同步問題。

• 修改建議：只在需要進行雙向同步時開啟。該參數需要重啟執行個體生效，應盡量在業務低峰期變更。

replication.oplogSizeMB

• 適用大版本：大於等於3.0

• 修改完是否需要重啟：否

• 預設值：規格的磁碟空間的10%（比如執行個體的磁碟大小是500GB，則初始oplogSizeMB就是51200，即50GB）

• 作用：指定用於儲存邏輯同步處理記錄的oplog表的最大值（邏輯大小）。

• 現象：參數設定過小，可能會導致從節點跟不上而進入異常的RECOVERING狀態；也有可能導致記錄備份來不及覆蓋所有oplog記錄而出現空洞，進而無法進行按時間點恢複。

• 修改建議：維持預設值，不要調小，需要時調大。如遇以下情境可適當調大該值：業務的workload屬於資料量不大但更新很多的情況，oplog產生速度比較快。此時適當調大oplogSizeMB可以使得oplog表能夠覆蓋更長時間的oplog記錄，避免出現oplog記錄空洞的問題。最佳實務為設定的oplogSize至少應可以保留1小時以上的oplog記錄。

  針對同一分區叢集不同分區磁碟大小不一致的情境，建議使用 storage.oplogMinRetentionHours 來控制 oplog 保留原則（4.4 及以上版本支援）。

setParameter.cursorTimeoutMillis

• 適用大版本：大於等於3.0

• 修改完是否需要重啟：否

• 預設值：600000（10min）

• 作用：空閒遊標的到期閾值，單位為毫秒。如果遊標的空閑時間超過該閾值，則MongoDB會自動清理該遊標。

• 現象：如果嘗試訪問一個已經被清理的到期遊標，用戶端側會收到以下格式的報錯：

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

• 修改建議：不建議調大，為了降低空閒遊標的資源開銷，可以適當調小（比如300000）。無論何種情境，業務側都應盡量避免出現長時間空閒遊標的情況。

setParameter.flowControlTargetLagSeconds

• 適用大版本：大於等於4.2

• 修改完是否需要重啟：否

• 預設值：10

• 作用：flowControl機制觸發的閾值，flowControl的目的是為了確保大多數提交點不會落後太多。

• 現象：出現類似下面的慢日誌（durationMillis基本等價於flowControl.timeAcquiringMicros，說明請求慢主要是受到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
    }
  }
  

• 修改建議：可以適當調大該參數，以此來降低flowControl機制介入的敏感度。如果調大後還是會出現請求經常被限流的情況，則說明執行個體在主從同步方面存在一定的效能瓶頸，需要進一步分析並採取其他方式來解決，比如升級執行個體配置或者將writeConcern設定為majority。

setParameter.oplogFetcherUsesExhaust

• 適用大版本：大於等於4.4

• 修改完是否需要重啟：是

• 預設值：true

• 作用：是否開啟流式複製（Stream Replication）。如果關閉此功能，主從同步將回退到與之前版本一致的拉取方式。即從節點給同步源發擷取一批oplog的請求，然後等待回複，這意味著每批oplog都需要一次網路往返的互動。

• 現象：部分情境下，流式複製機制可能會帶來額外的效能開銷和網路頻寬開銷。

• 修改建議：不建議調整。流式複製可以在高負載和高延遲的網路環境中減輕複寫延遲，還可以降低writeConcern為{w:1}時primary節點異常宕機時的寫入丟失風險，也可以降低其他依賴主從複製的writeConcern（比如{w:majority}或{w:>1}）下的寫入延遲。

setParameter.maxTransactionLockRequestTimeoutMillis

• 適用大版本：大於等於4.0

• 修改完是否需要重啟：否

• 預設值：5

• 作用：指定事務加鎖的逾時時間，單位為毫秒。如果事務裡的操作無法在給定的時間內擷取到需要的鎖，則事務會自動abort。

• 現象：在日誌中或者用戶端中遇到如下的鎖擷取逾時報錯資訊。（高版本驅動對於這種TransientTransactionError會自動重試，因此可能只在日誌中出現，用戶端側無法感知）

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

• 修改建議：如果用戶端側經常遇到類似的報錯，可以嘗試將此參數調大，能適當緩解瞬時並發鎖擷取不到而導致的事務中止，但相應地也會使得死結事務操作的中止延後。如果參數調大後問題依然出現，則不建議進一步調大參數，而是需要考慮從商務邏輯上進行最佳化，比如避免事務內對相同文檔的並發修改，以及重新審視事務裡的操作，檢查事務中是否包含了可能會長時間佔用鎖的操作（比如DDL、待最佳化的查詢），從源頭上避免類似問題發生。

setParameter.replWriterThreadCount

• 適用大版本：大於等於3.2

• 修改完是否需要重啟：是

• 預設值：16

• 作用：指定主從同步中並行複製的最大線程數，實際生效的最大線程數為執行個體規格CPU核心數的2倍。

• 現象：極端情境下可能出現主從同步不及時而從節點產生延遲（lag）不斷增大的情況。

• 修改建議：一般情況不建議調整。特殊情況推薦在阿里雲研發工程師的建議下來進行調整。

setParameter.tcmallocAggressiveMemoryDecommit

• 適用大版本：大於等於4.2

• 修改完是否需要重啟：否

• 預設值：0（代表關閉TCMalloc激進回收）

• 作用：MongoDB內部使用了TCMalloc作為記憶體 Clerk，此參數用於控制是否開啟TCMalloc的激進回收策略。開啟後，MongoDB會主動嘗試合并相鄰的空閑記憶體塊並歸還一部分記憶體給作業系統。

• 現象：

  • 因為查詢請求消耗過大，記憶體來不及回收而出現mongod節點OOM的情況。

  • 隨著不斷使用，堆記憶體片段空間越來越多，表現上為記憶體使用量率超過80%且穩定緩慢上升。

• 修改建議：一般情況不建議調整。有記憶體相關問題時可以考慮在業務低峰期時調整。

setParameter.transactionLifetimeLimitSeconds

• 適用大版本：大於等於4.0

• 修改完是否需要重啟：否

• 預設值：60

• 作用：指定事務的生命週期，單位為秒。如果事務的整體執行時間超過了此限制，會被標記為到期並被背景周期性清理線程主動處理並abort掉。

• 現象：用戶端側遇到格式如下的報錯：

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

• 修改建議：可以適當調小（比如到30），不建議調大。未提交的長事務可能會給WiredTiger儲存引擎的緩衝帶來很大壓力，一旦緩衝壓力超載通常會帶來更多問題，包括資料庫卡頓、請求延遲大幅增加、CPU使用率滿等，導致業務受損。無論如何，業務側都應該盡量避免長事務的出現。為瞭解決逾時問題，您應該將事務分解為更小的部分，以便在配置的時間限制內可以執行完成。您還需要確保已經最佳化過查詢語句，查詢語句具有適當的索引覆蓋率，以便在事務中快速存取資料。

關於事務使用的最佳實務，請參見事務與Read/Write Concern。

storage.oplogMinRetentionHours

• 適用大版本：大於等於4.4

• 修改完是否需要重啟：否

• 預設值：0（代表此參數不生效，oplog大小完全由前面提到的replication.oplogSizeMB參數控制）

• 作用：指定用於儲存邏輯同步處理記錄的oplog表的最小保留時間。

• 現象：

  • 參數設定過大，導致oplog表佔據過多磁碟空間。

  • 部分使用者忘記曾經設定過此參數，疑惑執行個體的磁碟空間大小波動原因。

• 修改建議：對於相對穩定的workload，維持預設值。對於可能會發生大幅度寫入操作變化的workload，建議將此參數配置為>1.0的浮點數。設定此參數時也需要評估可能的空間佔用，避免觸發磁碟滿鎖引發其他問題。

storage.wiredTiger.collectionConfig.blockCompressor

• 適用大版本：大於等於3.0

• 修改完是否需要重啟：是

• 預設值：snappy

• 作用：設定集合資料的儲存壓縮演算法（修改後僅對所有的建立的表生效，已存在的表不受影響）。目前支援設定為不壓縮或者snappy、zlib、zstd壓縮演算法（4.2及以上的版本才支援zstd）。

• 修改建議：按需修改。不同的壓縮演算法有著不同的表現，有的壓縮率更高但壓縮和解壓時的CPU開銷更大。實際壓縮演算法之間的對比，應以您實際測試的結果為準。如果執行個體主要用來儲存冷資料，那麼為了獲得更高的壓縮比，可以考慮將此參數修改為zstd。

  說明

  如果您想針對不同的表使用不同的壓縮演算法，需要使用帶相關選項的顯式createCollection命令，更多介紹，請參見MongoDB官方文檔。

setParameter.minSnapshotHistoryWindowInSeconds/setParameter.maxTargetSnapshotHistoryWindowInSeconds

• 適用大版本：大於等於4.4

• 修改完是否需要重啟：否

• 預設值：300（5分鐘）

• 作用：WT引擎保留快照（snapshot）歷史的視窗大小。單位為秒，0表示關閉快照歷史視窗。該參數主要用於支援atClusterTime的讀取。

• 現象：此參數會帶來一定的WT緩衝（WT cache）壓力，尤其是相同文檔頻繁更新的情境。

• 修改建議：一般情況無需調整。

  • 如果業務側確定不會使用讀歷史快照（read atClusterTime）的功能，可以將此參數調小到0，以獲得一定的效能提升。

  • 如果業務側希望能讀到早於5分鐘前的歷史快照資料，則可以將此參數調大。但也需要注意到調大後帶來的額外記憶體消耗和效能開銷。

  說明

  如果該參數值較小，而讀歷史快照時指定的時間更早，則會收到返回的SnapshotTooOld錯誤。

rsconf.chainingAllowed

• 適用大版本：大於等於4.0

• 修改完是否需要重啟：否

• 預設值：true

• 作用：是否允許複本集中的鏈式複製。

• 現象：

  • 關閉鏈式複製可能會導致主節點的負載上升（例如CPU使用率、網路流量等）。

  • 開啟鏈式複製可能會更容易出現從節點資料滯後。

• 修改建議：

  • 節點數少時（小於等於4個 ）：可以按需調整開啟或關閉鏈式複製。

  • 節點數多時（大於等於5個）：僅在writeConcern配置為{w:majority}時，您需要在主節點負載和執行個體效能之間做進一步的取捨，關閉鏈式複製有助於提升寫入效能，但相應的主節點負載也會顯著增加。

setParameter.internalQueryMaxPushBytes/setParameter.internalQueryMaxAddToSetBytes

• 適用大版本：大於等於4.2

• 修改完是否需要重啟：否

• 預設值：104857600 B（100 MB）

• 作用：限制$push和$addToSet運算元所能使用的最大記憶體值。

• 現象：特定的sql（包含$push或$addToSet）執行失敗，返回如下的錯誤資訊。

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

• 修改建議：一般情況無需調整。如果執行特定的SQL遇到了上述報錯，可以適當調大。但需注意，如果此參數設定得過大，可能會引起mongod節點出現OOM的情況。

setParameter.wiredTigerConcurrentReadTransactions/setParameter.wiredTigerConcurrentWriteTransactions

• 適用大版本：大於等於3.4

• 修改完是否需要重啟：分版本。

  • 3.4～6.0：否，運行時修改會直接調整對應的 ticket 池。

  • 7.0和8.0：分情況。

    • 如果執行個體已使用 fixedConcurrentTransactions 模式，修改讀寫 ticket 數無需重啟。

    • 預設情況下執行個體使用 throughputProbing 動態調整模式，此時直接修改本參數會失敗。若要使用固定 ticket 數，需在啟動配置中將 storageEngineConcurrencyAdjustmentAlgorithm 設定為 fixedConcurrentTransactions 並重啟執行個體。

  • 8.3及以上：否。支援運行時切換並發調整模式以及修改讀寫 ticket 數。

• 預設值：

  • 3.4～5.0：讀、寫 ticket 池各為 128。

  • 6.0～8.0：參數預設值為 0，表示啟動時由儲存引擎採用預設值，實際為讀、寫各 128。

  • 8.3及以上：讀、寫 ticket 池各為 128。

  說明

  7.0及以上版本預設啟用 throughputProbing 動態調整模式，系統會根據輸送量自動調整讀寫 ticket 數。此時上述固定參數的預設值不代表執行個體當前實際使用的 ticket 數。

  更高大版本對參數名進行了一些更新：6.0~8.0改名為 storageEngineConcurrentReadTransactions/storageEngineConcurrentWriteTransactions，8.3改名為 executionControlConcurrentReadTransactions/executionControlConcurrentWriteTransactions，但依然保留了對舊名稱的相容。

• 作用：

  • wiredTigerConcurrentReadTransactions 控制允許同時進入儲存引擎執行的最大並發讀事務數，即 read tickets 數量。

  • wiredTigerConcurrentWriteTransactions 控制允許同時進入儲存引擎執行的最大並發寫事務數，即 write tickets 數量。

  • 讀、寫分別使用獨立的 ticket 池。操作無法擷取 ticket 時會進入隊列等待。

  • ticket 是儲存引擎的並發控制機制，不等同於用戶端串連數、背景工作執行緒數或記憶體大小，不存在"每個 ticket 固定消耗多少記憶體"的通用計算公式。

• 現象：

  • read tickets 長期耗盡：

    • 查詢及 getMore 操作排隊，讀請求延遲升高。

    • 未使用串連池導致活躍並發請求突增、缺少合適索引導致掃描時間過長等情況，都可能使 read tickets 長時間被佔用。

  • write tickets 長期耗盡：

    • 寫請求排隊，業務寫延遲升高。

    • Secondary、唯讀節點和 Hidden 節點雖然不接收普通業務寫入，但需要回放 oplog，因此也會消耗 write tickets。write tickets 耗盡時可能伴隨複寫延遲擴大。普通查詢、全表掃描和 getMore 使用的是 read tickets，不會因為執行時間較長而轉為佔用 write tickets。但其佔用的 CPU、磁碟 I/O 和 WiredTiger Cache 資源可能間接拖慢複製回放。

• 修改建議：

  • 一般情況下無需調整。7.0及以上版本建議保留預設的 throughputProbing 動態調整模式。

  • 遇到 tickets 耗盡問題時，優先排查並處理可能的根因：1）應用使用串連池併合理限制活躍並發請求數；2）為慢查詢補充合適索引，避免不必要的全表掃描；3）檢查 CPU、磁碟 I/O、WiredTiger Cache、鎖競爭及複寫延遲是否已達到瓶頸。

  • 不建議僅因 available 為 0 就調大本參數。如果底層 CPU、磁碟或 Cache 已經飽和，調大 ticket 數會讓更多操作同時進入儲存引擎，可能加劇 I/O 排隊、Cache Eviction、鎖競爭和延遲抖動。

  • 沒有可按執行個體規格直接套用的推薦值。確認瓶頸確實來自 ticket 並發限制，且底層資源仍有餘量後，才可在業務低峰期小幅、逐次調整，並觀察一個完整業務周期。

  • 如果目的是限制並發、保護磁碟或 Cache，也可以在固定併發模式下適當調低，但會降低峰值吞吐能力。

  • 參數調整前後需持續觀察讀寫延遲、排隊時間、複寫延遲、磁碟利用率和 WiredTiger Cache Eviction 等指標。

  重要

  本參數當前未開放控制台自助調整。如確需調整，請提交工單，由支援人員評估。

  7.0和8.0預設使用動態調整模式，切換為固定併發模式需要重啟執行個體。切換後系統將不再根據輸送量自動調整 ticket 數，可能影響執行個體效能和穩定性，請勿僅為暫時緩解排隊而切換。

setParameter.migrateCloneInsertionBatchSize

• 適用大版本：大於等於4.0

• 修改完是否需要重啟：否

• 預設值：0（代表受16MB文檔大小限制）

  16MB 限制由 maxBSONObjectSize 參數控制，預設值 16MB，在ApsaraDB for MongoDB上不支援修改。業務需儲存超過 16MB 的文檔時，在業務層面拆分大文檔或使用 GridFS。GridFS 是 MongoDB 儲存大檔案的規範，將大檔案分割為多個 chunk 儲存，繞過單文檔大小限制。

• 作用：指定chunk遷移時複製步驟中單個批次的最大文檔數量。

• 現象：部分情境下，chunk遷移時可能會導致分區出現效能波動問題。

• 修改建議：一般情況無需調整。如果分區叢集執行個體在均衡期間因為chunk遷移而導致效能波動問題，可以考慮將此參數調整為一個固定的批次大小。

setParameter.rangeDeleterBatchDelayMS

• 適用大版本：大於等於 4.0

• 修改完是否需要重啟：否

• 預設值：20

• 作用：控制 chunk 遷移清理階段或 cleanupOrphaned 清理孤立文檔時，刪除批次之間的等待時間，單位為毫秒。

• 說明：

  • 0 表示批次之間不等待，不是恢複核心預設值。

  • 參數運行時修改後從下一批刪除開始生效；已經開始的 sleep 不會被提前喚醒。

• 現象：

  • 部分情境下，進行 chunk 遷移後的文檔非同步刪除時可能會導致 CPU 突增。

  • 參數設定過大會延長孤立文檔清理時間，導致待清理任務積壓；積壓嚴重時，後續與該範圍重疊的 chunk 遷移可能因等待清理逾時而失敗，出現下面的錯誤記錄檔：

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

• 修改建議：一般情況無需調整。如果分區叢集執行個體在均衡期間因為文檔非同步刪除而導致 CPU 使用率突增，可以考慮將此參數調大，比如調整為 200。單個大 range 刪除導致磁碟或 CPU 突增時，應先調小 rangeDeleterBatchSize，再酌情調大本參數；需要儘快清空孤立文檔時可臨時設為 0。

setParameter.rangeDeleterBatchSize

• 適用大版本：大於等於4.0

• 修改完是否需要重啟：否

• 預設值：

  • 4.4及以下：0（代表採用核心預設的批次大小，一般固定為128，且該值不隨規格變化）

  • 5.0及以上：2147483647（不限制單批次刪除文檔數，即一次性刪除整個range的待清理文檔）。注意：此版本區間顯式設為0等價於採用2147483647，而不是128。

• 作用：指定chunk遷移時清理步驟中批量非同步刪除單個批次的最大文檔數量。

• 現象：部分情境下，進行chunk遷移後的文檔非同步刪除時可能會導致CPU使用率或磁碟I/O突增。

• 修改建議：一般情況無需調整。如果分區叢集執行個體在均衡期間因為文檔非同步刪除而導致CPU或磁碟I/O突增，可以將此參數調小為一個固定的批次大小（如128或1000），並配合setParameter.rangeDeleterBatchDelayMS（預設20ms）適當調大批次間隔。兩個參數可分別調整、組合調整或漸進式調整。

setParameter.receiveChunkWaitForRangeDeleterTimeoutMS

• 適用大版本：大於等於4.4

• 修改完是否需要重啟：否

• 預設值：10000（10秒）

• 作用：指定Chunk遷移前等待刪除孤立文檔的逾時時間，單位為毫秒。

• 現象：Balancer運行過程中，您可能會看到如下的逾時錯誤記錄檔：

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

• 修改建議：一般情況無需調整。遇到上述報錯的情況下，可以將此參數適當調大，使得moveChunk操作可以等待刪除孤立文檔操作更長時間，以避免類似逾時錯誤。

setParameter.minSnapshotHistoryWindowInSeconds/setParameter.maxTargetSnapshotHistoryWindowInSeconds

• 適用大版本：大於等於4.4

• 修改完是否需要重啟：否

• 預設值：300（5分鐘）

• 作用：WT引擎保留快照（snapshot）歷史的視窗大小。單位為秒，0表示關閉快照歷史視窗。該參數主要用於支援atClusterTime的讀取。

• 現象：此參數會帶來一定的WT緩衝（WT cache）壓力，尤其是相同文檔頻繁更新的情境。

• 修改建議：一般情況無需調整。

  • 如果業務側確定不會使用讀歷史快照（read atClusterTime）的功能，可以將此參數調小到0，以獲得一定的效能提升。

  • 如果業務側希望能讀到早於5分鐘前的歷史快照資料，則可以將此參數調大。但也需要注意到調大後帶來的額外記憶體消耗和效能開銷。

  說明

  如果該參數值較小，而讀歷史快照時指定的時間更早，則會收到返回的SnapshotTooOld錯誤。

rsconf.chainingAllowed

• 適用大版本：大於等於4.0

• 修改完是否需要重啟：否

• 預設值：true

• 作用：是否允許Shard中的鏈式複製。

• 現象：

  • 關閉鏈式複製可能會導致主節點的負載上升（例如CPU使用率、網路流量等）。

  • 開啟鏈式複製可能會更容易出現從節點資料滯後。

• 修改建議：

  • 節點數少時（小於等於4個 ）：可以按需調整開啟或關閉鏈式複製。

  • 節點數多時（大於等於5個）：僅在writeConcern配置為{w:majority}時，您需要在主節點負載和執行個體效能之間做進一步的取捨，關閉鏈式複製有助於提升寫入效能，但相應的主節點負載也會顯著增加。

setParameter.periodicNoopIntervalSecs

• 適用大版本：大於等於4.2

• 修改完是否需要重啟：是

• 預設值：10

• 作用：空操作（noop）的寫入間隔時間，單位為秒。

• 現象：使用Change Stream時，如果某些分區上寫入較少，則該分區可能會成為mongos彙總分區變更的瓶頸，進而導致Change Stream出現一定程度的延遲（約10秒）。

• 修改建議：一般情況下無需調整。如果使用Change Stream時遇到上述延遲現象，可以考慮將該參數調小至1，以提升noop寫入頻率，避免Change Stream拉取因單個分區寫入較少而產生消費延遲。

setParameter.wiredTigerConcurrentReadTransactions/setParameter.wiredTigerConcurrentWriteTransactions

• 適用大版本：大於等於3.4

• 修改完是否需要重啟：分版本。

  • 3.4～6.0：否，運行時修改會直接調整對應的 ticket 池。

  • 7.0和8.0：分情況。

    • 如果執行個體已使用 fixedConcurrentTransactions 模式，修改讀寫 ticket 數無需重啟。

    • 預設情況下執行個體使用 throughputProbing 動態調整模式，此時直接修改本參數會失敗。若要使用固定 ticket 數，需在啟動配置中將 storageEngineConcurrencyAdjustmentAlgorithm 設定為 fixedConcurrentTransactions 並重啟執行個體。

  • 8.3及以上：否。支援運行時切換並發調整模式以及修改讀寫 ticket 數。

• 預設值：

  • 3.4～5.0：讀、寫 ticket 池各為 128。

  • 6.0～8.0：參數預設值為 0，表示啟動時由儲存引擎採用預設值，實際為讀、寫各 128。

  • 8.3及以上：讀、寫 ticket 池各為 128。

  說明

  7.0及以上版本預設啟用 throughputProbing 動態調整模式，系統會根據輸送量自動調整讀寫 ticket 數。此時上述固定參數的預設值不代表執行個體當前實際使用的 ticket 數。

  更高大版本對參數名進行了一些更新：6.0~8.0改名為 storageEngineConcurrentReadTransactions/storageEngineConcurrentWriteTransactions，8.3改名為 executionControlConcurrentReadTransactions/executionControlConcurrentWriteTransactions，但依然保留了對舊名稱的相容。

• 作用：

  • wiredTigerConcurrentReadTransactions 控制允許同時進入儲存引擎執行的最大並發讀事務數，即 read tickets 數量。

  • wiredTigerConcurrentWriteTransactions 控制允許同時進入儲存引擎執行的最大並發寫事務數，即 write tickets 數量。

  • 讀、寫分別使用獨立的 ticket 池。操作無法擷取 ticket 時會進入隊列等待。

  • ticket 是儲存引擎的並發控制機制，不等同於用戶端串連數、背景工作執行緒數或記憶體大小，不存在"每個 ticket 固定消耗多少記憶體"的通用計算公式。

• 現象：

  • read tickets 長期耗盡：

    • 查詢及 getMore 操作排隊，讀請求延遲升高。

    • 未使用串連池導致活躍並發請求突增、缺少合適索引導致掃描時間過長等情況，都可能使 read tickets 長時間被佔用。

  • write tickets 長期耗盡：

    • 寫請求排隊，業務寫延遲升高。

    • Secondary、唯讀節點和 Hidden 節點雖然不接收普通業務寫入，但需要回放 oplog，因此也會消耗 write tickets。write tickets 耗盡時可能伴隨複寫延遲擴大。普通查詢、全表掃描和 getMore 使用的是 read tickets，不會因為執行時間較長而轉為佔用 write tickets。但其佔用的 CPU、磁碟 I/O 和 WiredTiger Cache 資源可能間接拖慢複製回放。

• 修改建議：

  • 一般情況下無需調整。7.0及以上版本建議保留預設的 throughputProbing 動態調整模式。

  • 遇到 tickets 耗盡問題時，優先排查並處理可能的根因：1）應用使用串連池併合理限制活躍並發請求數；2）為慢查詢補充合適索引，避免不必要的全表掃描；3）檢查 CPU、磁碟 I/O、WiredTiger Cache、鎖競爭及複寫延遲是否已達到瓶頸。

  • 不建議僅因 available 為 0 就調大本參數。如果底層 CPU、磁碟或 Cache 已經飽和，調大 ticket 數會讓更多操作同時進入儲存引擎，可能加劇 I/O 排隊、Cache Eviction、鎖競爭和延遲抖動。

  • 沒有可按執行個體規格直接套用的推薦值。確認瓶頸確實來自 ticket 並發限制，且底層資源仍有餘量後，才可在業務低峰期小幅、逐次調整，並觀察一個完整業務周期。

  • 如果目的是限制並發、保護磁碟或 Cache，也可以在固定併發模式下適當調低，但會降低峰值吞吐能力。

  • 參數調整前後需持續觀察讀寫延遲、排隊時間、複寫延遲、磁碟利用率和 WiredTiger Cache Eviction 等指標。

  重要

  本參數當前未開放控制台自助調整。如確需調整，請提交工單，由支援人員評估。

  7.0和8.0預設使用動態調整模式，切換為固定併發模式需要重啟執行個體。切換後系統將不再根據輸送量自動調整 ticket 數，可能影響執行個體效能和穩定性，請勿僅為暫時緩解排隊而切換。

setParameter.internalQueryMaxPushBytes/setParameter.internalQueryMaxAddToSetBytes

• 適用大版本：大於等於4.2

• 修改完是否需要重啟：否

• 預設值：104857600 B（100 MB）

• 作用：限制$push和$addToSet運算元所能使用的最大記憶體值。

• 現象：特定的sql（包含$push或$addToSet）執行失敗，返回如下的錯誤資訊。

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

• 修改建議：一般情況無需調整。如果執行特定的SQL遇到了上述報錯，可以適當調大。但需注意，如果此參數設定得過大，可能會引起mongod節點出現OOM的情況。

operationProfiling.slowOpThresholdMs

• 適用大版本：大於等於3.0

• 修改完是否需要重啟：否

• 預設值：100

• 作用：定義一個查詢是否為慢查詢的閾值。

• 現象：

  • 參數設定過小，將導致產生大量慢日誌和審計日誌，帶來慢日誌噪音影響慢查詢分析。

  • 參數設定過大，將導致很多慢查詢並不輸出在日誌中，影響慢查詢分析過程。

• 修改建議：根據業務的實際情況適當調小或調大閾值，推薦設定為比業務核心查詢的平均耗時稍大些的值。樣本如下：

  • 假設一個對查詢延時比較敏感的業務，日常的查詢耗時都僅在30ms左右，為了協助分析一些瞬時抖動的慢查詢情況，可以將此參數調小到50。

  • 假設一個分析查詢比較重的業務，日常查詢耗時都在300~400ms左右，為了減少慢日誌噪音，可以將此參數調大到500ms。

setParameter.ShardingTaskExecutorPoolMaxConnecting

• 適用大版本：大於等於3.6

• 修改完是否需要重啟：

  • 3.6和4.0版本：是

  • 大於等於4.2版本：否

• 預設值：2

• 作用：指定分區叢集執行個體Mongos上TaskExecutor串連池初始化串連時的最大並發度。用來控制mongos到mongod的串連建立速度。

• 現象：如果該值設定較大，在觸發較多串連建立時，可能會引起Mongos的CPU使用率突增。

• 修改建議：不建議調整。

setParameter.ShardingTaskExecutorPoolMaxSize

• 適用大版本：大於等於3.6

• 修改完是否需要重啟：

  • 3.6和4.0版本：是

  • 大於等於4.2版本：否

• 預設值：2^64-1（int64類型的最大值）

• 作用：指定分區執行個體Mongos上每個TaskExecutor串連池的最大串連數。

• 修改建議：無需調整。如果期望限制Mongos到Shard之間的串連池上限，可以設定，但不建議設定得太小，否則會導致串連池耗盡時Mongos上請求阻塞等待的問題。

setParameter.ShardingTaskExecutorPoolMinSize

• 適用大版本：大於等於3.6

• 修改完是否需要重啟：

  • 3.6和4.0版本：是

  • 大於等於4.2版本：否

• 預設值：1

• 作用：指定分區叢集執行個體Mongos上每個TaskExecutor串連池的最小串連數。

• 現象：部分情境下，Mongos上突發的請求可能會導致TaskExecutor串連池需要額外建立很多串連，從而引起Mongos上的CPU突增以及其他問題。

• 修改建議：建議設定為[10,50]間的合理值，具體多少應該取決於分區執行個體的拓撲結構（分區數以及分區內的節點數）。請注意，Mongos維護這些到Shard上的空閑串連會有少量資源開銷。

setParameter.cursorTimeoutMillis

• 適用大版本：大於等於3.0

• 修改完是否需要重啟：否

• 預設值：600000（10min）

• 作用：空閒遊標的到期閾值，單位為毫秒。如果遊標的空閑時間超過該閾值，則MongoDB會自動清理該遊標。

• 現象：如果嘗試訪問一個已經被清理的到期遊標，用戶端側會收到以下格式的報錯：

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

• 修改建議：不建議調大，為了降低空閒遊標的資源開銷，可以適當調小（比如到300000）。無論如何，業務側都應盡量避免出現長時間空閒遊標的情況。