Mongo 3.6 性能問題
我們有一個完全駐留在 AWS 中的 3 節點 Mongodb 副本集。主要是 i3.2xlarge（8 核 61G RAM），而次要成員是 i3.xlarge（4 核 30.5G RAM）。這些實例每個都由兩個 SSD EBS 卷支持，其中一對的 XFS 格式僅用於 Mongodb 安裝。Mongodb 安裝使用 WiredTiger 儲存引擎。mongod.conf 在這裡。
我們有一個大約每週一次的 ETL 過程，它使用 Pentaho 通過基於 Tomcat8 的 REST API 寫入我們的副本集。這個過程在過去的兩年裡一直順利完成，直到我們在 2 月底升級到 Mongodb 3.6。在 Mongodb 3.6 上第一次執行此程序期間，mongod 程序將實例執行到記憶體不足。作業系統呼叫 oom-killer 來停止程序。在隨後的選舉之後，該程序也殺死了新的主節點。
我們以前從未為實例配置交換空間，但在此事件之後，在每個實例上都配置了交換空間，在
$$ RAM x 2 $$大小的 AWS NVMe 實例儲存卷。自實施交換空間以來，任何密集型程序都將繼續將實例執行到小於 1G 的記憶體，然後滾動到交換空間。我們不再遇到 mongod 服務崩潰的情況，但係統會定期用盡所有可用記憶體，以及多達一半的交換空間。例如，系統昨天處於這種狀態，在重新啟動服務時釋放了記憶體和交換空間，夜間轉儲使系統使用了 26/60G 記憶體。一旦不再積極使用該服務似乎就不會釋放記憶體/殺死執行緒（見下圖）。
. 其他系統詳情：
- Ubuntu 14.04.5
- 4.4.0-112-generic #135~14.04.1-Ubuntu SMP
- MongoDB 3.6.2
- transparent_hugepage & defrag 設置為“從不”
- 預讀設置為 16K
- 安裝了 numactl，允許通過 init 腳本禁用 NUMA
對於將來尋找此問題答案的任何人，我們發現這是由於MongoDB 的 3.0 > 3.2 版本中的一個錯誤。不幸的是，我們不得不花費承包商的錢來解決這個問題，但至少我們的副本集再次起作用。
根據您的系統詳細資訊，
readahead設置為 16K。但根據WiredTiger 儲存引擎的MongoDB BOL。無論儲存介質類型（旋轉、SSD 等）如何，都將預讀設置設置為0 。設置較高的
readahead好處是順序 I/O 操作。但是，由於 MongoDB 磁碟訪問模式通常是隨機的，因此設置更高的預讀會帶來有限的好處或性能下降。因此，對於大多數工作負載，a**readahead**為 0 可提供最佳 MongoDB 性能。通常，將設置設置為 0，除非測試以較高的值readahead顯示可測量、可重複和可靠的好處。MongoDB 專業支持可以提供關於非零預讀配置的建議和指導。readahead作為 WiredTiger 的 MongoDB 文件，請考慮以下有關 Linux 環境的建議：
- 關閉**
atime**包含數據庫文件的儲存卷。- 根據ulimit參考中的建議，將文件描述符限制
-n和使用者程序限制 ( ulimit )設置-u為 20,000 以上 。低ulimit在大量使用時會影響 MongoDB，並可能產生錯誤並導致與 MongoDB 程序的連接失敗和服務失去。- 禁用透明大頁面。MongoDB 在正常（4096 字節）虛擬記憶體頁面上表現更好。請參閱透明大頁面設置。
- 在 BIOS 中禁用 NUMA。如果這不可能，請參閱NUMA 硬體上的 MongoDB。