MongoDB的WiredTiger存儲引擎，用了一段時間，遇到了一些問題，通過優化WT參數，也解決了一些問題，做個小結。
-
cache_size
指定WT存儲引擎內部cache的內存用量上限。
需要注意的是，僅作用於WiredTiger cache，而非mongod進程的內存用量上限。MongoDB同時使用WT cache和文件系統cache，往往mongod進程的內存用量高於該值。cache_size相對於物理內存總量不要設置的太滿，需要留有一定內存爲操作系統所用，否則有OOM潛在風險。
默認情況下，cache_used超過80%將觸發eviction，如果物理內存充足，建議設置足夠大的cache_size，以加載全部數據，避免不必要的eviction。
個人經驗值 cache_size = (data + index) / 0.8
cache_size支持在不停服的情況下動態調整，比如將cache_size設置爲80GB，執行如下命令：
db.adminCommand({setParameter: 1, wiredTigerEngineRuntimeConfig: "cache_size=80G"}) -
eviction
cache_used是很關鍵的指標，超過80%將觸發eviction，類似LRU算法，淘汰冷數據，避免cache用量持續增長。
一個健康的MongoDB服務，其cache_used應該不超過80%，即使超過，能在短時間內降到80%也是沒問題的。如果長時間高於80%則需要重視起來，因爲cache_used過高會導致數據庫性能下降，體現在慢操作（讀寫請求耗時長）、qr/qw高（讀寫請求排隊）等方面。所以我們要極力保證cache_used在一個健康的範圍內。
eviction包括很多參數，比如
eviction_trigger、eviction_target、eviction_dirty_target等，指定在什麼條件下觸發和停止cache eviction，這裏，我更關心的是eviction線程數量。對於eviction線程，MongoDB默認配置是
eviction=(threads_min=1,threads_max=4)，根據cache使用情況，創建1-4個eviction線程去淘汰冷數據。如果cache體積較大、讀寫頻繁，那麼需要更多的eviction線程。
如果調高threads_max仍然無法降低cache_used，建議設置更大的cache_size
動態調整配置：
db.adminCommand({setParameter: 1, wiredTigerEngineRuntimeConfig: "eviction=(threads_min=1,threads_max=8)"}) -
wiredTigerConcurrentWriteTransactions
指定最大併發寫事務數。
對於寫頻繁的服務，通過mongostat查看運行狀態，如果qw持續較高、aw經常是128（默認值），說明寫請求發生排隊，同時WT無法提供更高的併發寫。
此時觀察CPU負載，如果負載不高（相對於核數，CPU未充分利用），嘗試調高此參數，能夠一定程度上緩解問題，即使出現qw高，往往也是短暫的，可能下一秒恢復正常。
調高此參數，相當於壓榨CPU，CPU負載較之前會有一定增加，如果負載在合理範圍內，可以接受；負載過高的話，建議擴容。
建議根據實際情況動態調整，並持續觀察效果，找到一個合理的值。
查看當前配置：
db.adminCommand({getParameter: 1, wiredTigerConcurrentWriteTransactions: 1}) or db.adminCommand({getParameter: '*'}).wiredTigerConcurrentWriteTransactions動態調整配置：
db.adminCommand({setParameter: 1, wiredTigerConcurrentWriteTransactions: 512})
參考