由於 Mongo 使用所有系統記憶體，MongoDB 複製受到限制
我們有一個執行 MongoDB 3.4 的小型三成員副本集：
- 基本的。物理本地伺服器，Windows Server 2012，64 GB RAM，6 核。在斯堪的納維亞舉辦。
- 次要的。Amazon EC2、Windows Server 2016、r4.2xlarge、61 GB RAM、8 個 vCPU。在德國舉辦。
- 仲裁者。微型基於雲的 Linux 實例。
我們注意到，從主節點到次節點的複制速度被限制（上限）在剛剛超過 20 MBit/s，即它不會超過該速度。如果有更多數據要複製，它將排隊，我們將有複製滯後。
這不是純粹的頻寬問題；例如，在進行節流時，我們可以通過 FTP 在兩台伺服器之間以遠超過 20 MBit/s 的速度傳輸數據。此外，有時，特別是在 MongoDB 重新啟動後，限制會停止幾天，然後又回來。日誌中沒有任何內容描述原因。
經過大量的實驗和調試，我們發現了限流的問題：隨著時間的推移，MongoDB 將消耗主要成員上的所有可用記憶體。一旦達到此狀態（通常在重新啟動後幾天），就會開始限制。大約一半的記憶體是 MongoDB 程序本身（WiredTiger 記憶體），其餘的則由記憶體映射集合消耗。這似乎是設計使然，根據MongoDB 網站：“通過文件系統記憶體，MongoDB 自動使用 WiredTiger 記憶體或其他程序未使用的所有空閒記憶體。”
現在開始提問：
- 誰能想到低可用記憶體導致複製限制的原因？
- MongoDB中有沒有辦法限制用於記憶體映射的記憶體量？（我們還沒有找到。）
- Windows中是否有推薦的方法來做同樣的事情？（感覺解決問題的方法不對。）
目前，我們有一個非常老套的解決方法：我們有一個小的 .NET 腳本，它持續監控可用記憶體，當可用記憶體不足時，它分配 10 GB 記憶體（將從 MongoDB 獲取），然後立即釋放它。結果是伺服器有 10 GB 可用記憶體，MongoDB 大約需要 1 天才能填滿，在此期間沒有限制。是的，這個腳本實際上解決了這個問題:)
這聽起來像是WT-2670修復的錯誤，其中映射的記憶體在不再使用時不會自動釋放。您是否嘗試過升級到最新版本？
我從未見過複製速度的限制，但我正在使用 Linux mongodb 機器。我想在 Windows 世界中它可能會發生，當程序吃掉所有記憶體時，Windows 作業系統正在節流。我記得讀到當 mongod 使用所有可用記憶體時，Windows 作業系統存在“問題”。
為了控制 mongod 可以使用多少記憶體，在 Linux 中，您可以使用 cgroups，因此如果您在 windows 中使用“容器”（docker），您可以控制 mongod 獲得多少資源。