MongoDB 從 3.0 開始引入可插拔儲存引擎的概念。當前，有不少儲存引擎可供選擇： MMAPV1 、 WiredTiger 、 MongoRocks 、 TokuSE 等等。每個儲存引擎都有自己的優勢，你需要根據效能要求及應用特徵挑選最適合的一個。

從 3.2.x 開始， WiredTiger 成為預設的儲存引擎。最為 MongoDB 目前最流行的儲存引擎， WiredTiger 與原先的 MMAPV1 相比有以下優勢：

• 效能&併發 ：在大多數工作負載下， WiredTiger 的效能要比 MMAPV1 高很多。 WiredTiger 引擎為現代多核系統量身定製，更好地發揮多核系統的處理能力。 MMAPV1 引擎使用表級鎖，因此，當某個單表上有併發的操作，吞吐將受到限制。 WiredTiger 使用文件級鎖，由此帶來併發及吞吐的提高。對於典型的應用，切到 WiredTiger 引擎，可帶來5-10倍的效能提升。

• 壓縮&加密 ： MMAPV1 引擎要求資料在記憶體和在磁碟的形式一致(map磁碟記憶體對映)。因此，它並不支援壓縮和加密。 WiredTiger 並沒有這層限制，可以更好地支援。

• 索引字首壓縮 ： WiredTiger 儲存索引時使用字首壓縮——相同的字首只存一次。由此帶來的效果是：索引更小了，對實體記憶體使用也更少了。

接下來，我會展示幾個用來調優 WiredTiger 引擎效能的關鍵引數。

調優Cache Size

WiredTiger 最重要的調優引數就是 cache 規模。預設， MongoDB 從 3.x 開始會保留可用實體記憶體的50%( 3.2 是60%)作為資料 cache 。雖然，預設的設定可以應對大部分的應用，透過調節為特定應用找到最佳配置值還是非常值得的。 cache 的規模必須足夠大，以便儲存應用整個工作集(working set)。

除了這個 cache ， MongoDB 在做諸如聚合、排序、連線管理等操作時需要額外的記憶體。因此，必須確保有足夠的記憶體可供使用，否則， MongoDB 程式有被 OOM killer 殺死的風險。

調節這個引數，首先要理解在預設配置下， cache 的使用情況。執行以下命令，可以獲得 cache 統計：

db.serverStatus().wiredTiger.cache

命令輸出結果例子如下：

{   "tracked dirty bytes in the cache" : 409861,   "tracked bytes belonging to internal pages in the cache" : 738956332,   "bytes currently in the cache" : 25769360777,   "tracked bytes belonging to leaf pages in the cache" : 31473298388,   "maximum bytes configured" : 32212254720,   "tracked bytes belonging to overflow pages in the cache" : 0,   "bytes read into cache" : 29628550664,   "bytes written from cache" : 34634778285,   "pages evicted by application threads" : 0,   "checkpoint blocked page eviction" : 102,   "unmodified pages evicted" : 333277,   "page split during eviction deepened the tree" : 0,   "modified pages evicted" : 437117,   "pages selected for eviction unable to be evicted" : 44825,   "pages evicted because they exceeded the in-memory maximum" : 74,   "pages evicted because they had chains of deleted items" : 33725,   "failed eviction of pages that exceeded the in-memory maximum" : 1518,   "hazard pointer blocked page eviction" : 34814,   "internal pages evicted" : 21623,   "maximum page size at eviction" : 10486876,   "eviction server candidate queue empty when topping up" : 8235,   "eviction server candidate queue not empty when topping up" : 3020,   "eviction server evicting pages" : 191708,   "eviction server populating queue, but not evicting pages" : 2996,   "eviction server unable to reach eviction goal" : 0,   "pages split during eviction" : 8821,   "pages walked for eviction" : 157970002,   "eviction worker thread evicting pages" : 563015,   "in-memory page splits" : 52,   "percentage overhead" : 8,   "tracked dirty pages in the cache" : 9,   "pages currently held in the cache" : 1499798,   "pages read into cache" : 2260232,   "pages written from cache" : 3018846}

第一個要關注的數值試， cache 中髒資料的百分比。如果這個百分比比較高，那麼調大 cache 規模很有可能可以提升效能。如果應用是重讀的，可再關注 bytes read into cache 這個指標。如果這個指標比較高，那麼調大 cache 規模很有可能可以提升讀效能。

調節 cache 規模不一定非得重啟服務，我們可以動態調整：

db.adminCommand( { "setParameter": 1, "wiredTigerEngineRuntimeConfig": "cache_size=xxG"})

如果你想讓調整在重啟後也有效，那麼你需要將配置檔案也相應調整一下。

控制Read/Write Tickets

WiredTiger使用 tickets 來控制可以同時被儲存引擎處理的讀/寫運算元。預設值是128，在大部分情況下表現良好。如果這個值經常掉到0，所有後續操作將會被排隊等待。例如，觀察到讀 tickets 下降，系統可能有大量長耗時的操作(未索引操作)。如果你想找出有哪些慢操作，可以用一些第三方工具。你可以根據系統需要和效能影響上下調節 tickets 。

執行以下命令可以確認 tickets 的使用情況：

db.serverStatus().wiredTiger.concurrentTransactions

下面是一個輸出例子：

{   "write" : {      "out" : 0,      "available" : 128,      "totalTickets" : 128
   },   "read" : {      "out" : 3,      "available" : 128,      "totalTickets" : 128
   }
}

同樣，可以動態調節 tickets ：

db.adminCommand( { setParameter: 1, wiredTigerConcurrentReadTransactions: xx } )db.adminCommand( { setParameter: 1, wiredTigerConcurrentWriteTransactions: xx } )

一旦做出調整，注意要觀察系統的效能監控確保影響是符合預期的。

本文譯自： Tips for MongoDB WiredTiger Performance Tuning 。

             

作者：fasionchan
連結：
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯絡作者獲得授權並註明出處。