譯注：
本文是翻譯MongoDB Manuel中的MongoDB Production Notes一節內容。這節內容重點關注生產環境中影響性能和可靠性的各種注意事項，值得正在部署MongoDB的工作者們關注。以下是正文。
本文詳細描述了影響MongoDB，特別是生產環境的關鍵系統配置。
注意：MongoDB管理服務（MMS）是一個托管監控服務，它收集並聚合診斷數據，為MongoDB部署集提供更直觀的性能和操作情況概覽。更多內容請查看MMS網站和MMS文檔。
安裝包
MongoDB
確保你安裝了最新的穩定版本。所有穩定版本都發布在下載頁。這是了解最新版本的最佳場所，即使你稍后選擇從包管理器安裝。
生產環境始終使用64位版本。32位版本是為測試和部署環境准備的，不適於生產環境部署，因為它只能存儲2GB以內的數據。了解更多內容請查看32位限制。
32位版本的存在是為滿足非正式環境的使用場景。
操作系統
MongoDB發行版目前可用於Max OS X，Linux，Windows Server 2008 R2 64位版，Windows 7（32位及64位版），Windows Vista，以及Solaris平台。
注意：在可能的情況下，MongoDB使用GNU C庫（glibc）。MongoDB要求版本至少在glibc-2.12-1.2.el6以避免早先版本一個已知的Bug。為了效果最佳請使用至少2.13版本。
並發
早先版本的MongoDB中所有寫操作都集中使用實例中的唯一一個讀寫鎖。從2.2開始，每個數據庫開始具有一個獨立的讀寫鎖，這使得一個數據庫可以並發讀，同時每個數據庫有了獨立的寫控制。查看並發頁了解更多信息。
日志
MongoDB使用預先寫日志到磁盤日志的辦法來保證MongoDB能夠快速從崩潰或其他嚴重錯誤中恢復寫操作。
為了保證mongod能夠從崩潰中恢復並繼續處於可用狀態，你應該啟用日志。查看日志頁以了解更多內容。
網絡
使用可信任網絡環境
始終在可信任環境中運行MongoDB，並啟用網絡策略禁止未知機器，系統和網絡訪問。猶如依賴網絡訪問的任何一個敏感系統一樣，你的MongoDB環境應該只為指定的，需要訪問的系統開發，例如應用程序服務器，監控服務及其他MongoDB組件。
注意：默認情況下認證功能未開啟，mongod推斷自己處於可信任環境中。如有必要你可以啟用安全認證模式。
查看安全章節的內容以了解更多信息。特別是：
對於Windows用戶，在Windows上部署MongoDB時考慮Windows Server TCP技術文章中的內容。
連接池
為避免單個mongod或mongos實例連接資源越負荷，請確保客戶端維護了合理數量的連接池配置。
connPoolStats數據庫命令能夠返回一個分片集群里mongos和mongod實例中當前數據庫打開連接的信息。
硬件考量
MongoDB的設計是基於兼容大多數硬件考慮，幾乎沒有特別的要求或限制。MongoDB的核心組件能夠運行於小端字節優先的硬件，主要是x86/x86_64處理器上。客戶端類庫（例如驅動）在大端優先或小端優先系統上都可以運行。
硬件需求和限制
能夠讓MongoDB最有效率地運行的硬件應該包含以下特性：
分配了足夠的內存和CPU
猶如對於所有軟件一樣，更多的內存和更快的CPU時鍾頻率對於性能很重要。
基本上，數據庫並非受限於CPU。因此，增加核心數量雖然有幫助，但不會提供顯著的回報。
使用固態硬盤（SSD）
MongoDB使用SATA SSD能得到很好的效果和很好的性價比。
在足夠經濟的情況下請使用SSD。傳統硬盤也可能很有效率，但SSD對於隨機IO訪問的良好支持更符合mongod的數據更新模型。
傳統硬盤通常也是個好的選擇，因為使用更昂貴的硬盤來提高隨機IO性能並不是那么有效（只能是每次2倍）。使用SSD或增加RAM的容量可能對於提升IO更有效率。
避免使用遠程文件系統
遠程文件存儲系統可能對MongoDB造成性能問題。查看遠程文件系統了解更多關於MongoDB和存儲的信息。
MongoDB和NUMA硬件
重要：這里討論的NUMA僅限於Linux系統，因此不影響運行於其他類Unix系統或Windows系統。
在運行NUMA的系統中運行MongoDB可能造成一系列問題，包括一段時間內的效率低下和高系統進行使用率。
當運行MongoDB在NUMA硬件上時，你應該為MongoDB禁用NUMA並使用Interleave內存策略。
注意：MongoDB 2.0以上版本如果部署在Linux系統上，啟動時會檢查系統配置，如果系統是基於NUMA的，會給出警告。
為禁用NUMA並啟用interleave內存策略，請使用numactl並使用以下方式啟動mongod
numactl --interleave=all /usr/bin/local/mongod
然后，為了禁用proc配置中的zone reclaim，請使用以下命令：
echo 0 > /proc/sys/vm/zone_reclaim_mode
為了徹底禁用NUMA，你必須操作以上兩步。了解更多信息，請查看/proc/sys/vm/*文檔。
查看MySQL“瘋狂交換”問題和NUMA效果一文，它描述了NUMA對數據庫造成的影響。這篇博客確定了NUMA對MySQL的影響，但對於MongoDB的影響也是類似的。這篇文章介紹了NUMA和它的目標，並指出了為什么這些目標和生產環境數據庫的需求是不相容的。
磁盤和存儲系統
虛擬內存
為你的系統分配虛擬內存。分配虛擬內存可以避免內存爭搶問題，同時可以阻止Linux系統的OOM Killer殺死mongod。
mongod使用的映射內存文件到內存的方法可以確保操作系統從來不會把MongoDB數據放進虛擬內存。
RAID
絕大多數MongoDB應該使用RAID-10磁盤系統。
RAID-5和RAID-6典型情況下不能為MongoDB提供足夠好的性能。
MongoDB應該避免使用RAID-0。RAID-0提供了足夠好的寫性能，但它只能提供有限的可用性，並且可能導致讀操作性能低下，特別是在Amazon EBS卷上。
遠程文件系統
MongoDB不推薦使用網絡文件系統（NFS），因為一些版本的NFS性能低下。
當數據文件和日志文件同時位於NFS上時就會發生性能問題。如果你把日志放到本地或iscsi上則可能得到更好的性能體驗。如果必須使用NFS，添加以下NFS選項到你的/etc/fstab文件：bg,nolock及noatime。
把不同的組件放到不同的存儲設備
為了提高性能，考慮把你的數據庫的數據，數據日志和應用日志按照你的應用程序的讀寫模式放到不同的存儲設備上。
注意：這會影響你創建數據快照的能力。因為文件會在不同的設備和卷上。
架構
Write Concern
Write Concern描述了MongoDB報告成功寫操作時是如何確保它是成功的。Write Concern的強度決定了保證成功的等級。當插入，更新或刪除有一個等級比較弱的Write Concern的時候，寫操作能夠迅速返回。在一些失敗的場景中，具備較彈的Write Concern的寫操作可能不能被持久化。具有更強的Write Concern時，客戶端會等到MongoDB確認了這個寫操作成功為止。
MongoDB提供了不同等級的Write Concern來滿足不同應用的不同需求。客戶端可以通過調整Write Concern來確定最重要的操作始終成功持久化到整個MongoDB集群。對於其他不那么重要的操作，客戶端調整Write Concern以保證更好的性能，而不是等待整個集群完成持久化。
查看Write Concern章節以獲取更多關於如何選擇合適你的MongoDB集群的Write Concern等級的信息。
Replica Set
查看Replica Set部署架構章節以了解Replica Set集群的整體架構和需要考慮的問題。
分片集群
查看生產環境集群架構章節以了解生產環境分片集群的推薦架構情況。
平台
在Linux上運行MongoDB
重要：以下討論只適用於Linux，因此不影響mongod在其他類Unix系統或Windows系統的部署。
內核和文件系統
當在生產環境中讓MongoDB運行於Linux上時，推薦使用Linux內核版本2.6.36或更新版本。
MongoDB會在使用前預先分配數據文件，通常會是一個比較大的文件。因此，你應該使用Ext4或XFS文件系統：
- 總體上，如果你使用Ext4文件系統，使用至少2.6.23以上的Linux內核。
- 總體上，如果你使用XFS文件系統，使用至少2.6.25以上的Linux內核。
- 一些Linux發行版在運行ext4和/或XFS時要求不同的Linux內核版本：
| Linux Distribution | Filesystem | Kernel Version |
|---|---|---|
| CentOS 5.5 | ext4, xfs | 2.6.18-194.el5 |
| CentOS 5.6 | ext4, xfs | 2.6.18-238.el5 |
| CentOS 5.8 | ext4, xfs | 2.6.18-308.8.2.el5 |
| CentOS 6.1 | ext4, xfs | 2.6.32-131.0.15.el6.x86_64 |
| RHEL 5.6 | ext4 | 2.6.18-238 |
| RHEL 6.0 | xfs | 2.6.32-71 |
| Ubuntu 10.04.4 LTS | ext4, xfs | 2.6.32-38-server |
| Amazon Linux AMI release 2012.03 | ext4 | 3.2.12-3.2.4.amzn1.x86_64 |
重要：MongoDB要求文件系統對目錄支持fsync()。所以例如HGFS和Virtual Box的共享目錄不支持這個操作。
推薦配置
- 在包含數據文件的卷關閉atime配置。
- 按照UNIX ulimit設置的推薦，設置描述符限制，-n及其他用戶進程限制（ulimit），-u到多於20000。較低的ulimit配置在大壓力情況下會影響MongoDB，並且可能產生錯誤及導致連接到MongoDB失敗和服務不可用。
- 不要使用hugepages虛擬內存頁，因為MongoDB在正常虛擬內存頁中表現更好。
- 在BIOS中禁用NUMA。如果做不到，請參考MongoDB和NUMA硬件章節。
- 確保存放數據文件的塊設備的readahead配置合理。對隨機訪問模式，設置較低的readahead值。readahead 32（或16kb）通常工作良好。
- 使用網絡時間協議（NTP）保證服務器間的時間同步。這對於分片集群來說尤其重要。
虛擬環境中的MongoDB
本章節描述了在常用虛擬環境中運行MongoDB需要考慮的問題。
EC2
MongoDB與EC2環境兼容，不需要指定特別的環境配置。
作為選擇之一，你也可以選擇一組綁定了MongoDB和提供了Amazon Provisioned IOPS卷的Amazon機器映像（AMI）。Provisioned IOPS能夠極大地增進MongoDB的性能和易用性。查看這篇博客以了解更多信息。
VMWare
MongoDB兼容VMWare。如果用戶陷入VMWare的內存過量使用特性問題，推薦禁用掉這個特性。
克隆一個正在運行MongoDB的虛擬機是可能的。你可以使用這個特性來配置一個新的虛擬主機，並把它加入到Replica Set中。如果你克隆了一台啟用日志的VM，克隆出來的快照將是可用的。如果沒有啟用日志，需要先信用mongod，克隆VM，最后重新啟動mongod。
OpenVZ
有些用戶在運行老版本的OpenVZ上運行MongoDB上遇到問題是因為它處理虛擬內存的方式，跟VMWare類似原因。
這個問題看起來在最近的OpenVZ版本中已經解決了。
性能監控
iostat
在Linux上，可以使用iostat命令檢查磁盤IO是否是你的數據庫的瓶頸。在使用iostat時指定一個更新時間秒數，以避免得到的是自機器啟動以來的平均IO統計。
例如，以下命令將會以每份報告中顯示擴展統計，帶有MB/s為單位的流量統計，每秒統計一次：
iostat -xmt 1
iostat的關鍵字段：
- %util: 這是快速檢查時最有用的字段。它指示設備/驅動器占用了處理時間的多少百分比。
- avgrq-sz: 平均請求大小。越小的值代表越隨機的IO操作。
bwm-ng
bwm-ng是用於監控網絡流量的命令行工具。如果你懷疑網絡遇到瓶頸，則可以使用bwm-ng來啟動診斷流程。
備份
為了備份MongoDB數據庫，請檢查MongoDB備份方法。