译注：
本文是翻译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备份方法。
