MongoDB只支持64位的操作系统。安装MMAPv1存储引擎的MongoDB支持32位系统，但是仅仅是为老系统提供向后兼容的作用。WiredTiger存储引擎的MongoDB不支持32位操作系统。
生产环境中MongoDB应该部署在Linux2.6.36内核版本或者以上版本中，使用EXT4或者XFS文件系统；避免使用EXT3，EXT3文件系统是非常古老的文件系统，对数据库系统来说不是***的选择。比如，MMAPv1会为数据预分配空间。EXT3文件系统中，预分配操作实际上会写0s到硬盘中以实现空间分配，这是非常耗时的。EXT4和XFS文件系统中，预分配是当做逻辑操作执行的，所以更高效。
使用WiredTiger时，强烈建议使用XFS避免使用EXT4时出现的性能问题。
Linux中部署MongoDB时可以参考以下推荐的配置：
l 关闭数据库文件存储卷的atime属性
l 不要使用HugePages这样的虚拟内存页，使用正常的虚拟内存页MongoDB会表现更好
l 在BIOS中关闭NUMA或者在mongod中禁用UNMA
l 确保存储数据文件的块设备的readahead属性相对较小，因为大部分读取都是非顺序的。比如，可以把readahead设置成32（16KB）。
l 使用NTP这样的同步服务器保证各个主机之间的时间同步，这在分片集群中尤其重要。在虚拟机上部署的MongoDB同样需要注意这个问题。
Linux系统可以控制每个进程和每个用户上打开的文件以及资源的数量。默认的设置堆MongoDB系统是足够用的。通常情况下，一个操作系统、虚拟机和容器上应该只运行MongoDB进程以保证MongoDB不用跟其他进程进行资源抢夺。
由于每个部署的系统对资源的要求都是独一无二的，以下的几个推荐配置可以用在mongod和mongos实例中。使用ulimit属性来应用这些设置：
l -f（文件大小）：不限制
l -t（CPU时间）：不限制
l -v（虚拟内存）：不限制
l -n（打开文件数）：大于20000
l -m（内存大小）：不限制
l -u（进程数量）：大于20000
使用ulimit为MongoDB进行资源限制的更过信息可以参考MongoDB文档中Linux ulimit Settings章节
网络管理员需要永远保证MongoDB运行在一个可信任的网络环境中，防止未知应用对数据库进行访问。与MongoDB系统进行交互的预知进程是有限的：应用服务器、监控进程、以及运行在复制集和分片集群上的其他MongoDB进程。
MongoDB的进程默认都是与系统上的网络接口进行绑定的。如果你的系统不止一个网络接口，你就需要把你的MongoDB进程与私有接口或者内部网络接口进行绑定。
MongoDB Security Tutorials章节中有关于MongoDB默认端口数量、MongoDB防火墙设置、***以及相关话题的更多详情。本手册后面的内容也会提及系统部署的安全方面的***实践。
在虚拟机上运行时，使用半虚拟化驱动程序来实现优化的网络和存储接口，以最小的开销在虚拟机和管理程序之间传递指令
集群内网络压缩作为分布式数据库系统，MongoDB依赖于查询路由与复制集节点指点高效的网络传输。MongoDB3.4引进了一种新的方式对集群之间的信息往来进行网络压缩。基于snappy压缩算法，网络压力可以被压缩到70%以上，不仅可以在宽带有限的环境中提高性能，还能减少网络消耗。
压缩功能默认是关闭的，可以设置networkMessageCompressors为snappy以打开压缩功能。压缩和解压缩会增加CPU的负载，一般会占用百分之几的负载。在CPU资源比较足但是宽带成为性能瓶颈的环境中使用压缩功能是非常理想的。
生产验证的建议关于操作系统、文件系统、存储设备以及其他相关话题的配置的最新意见可以参考MongoDB Production Notes。
持续可用性正常操作情况下，MongoDB系统的表现会根据性能以及功能需求来确定。但是，总会有一些必然的故障或者意外的操作会以不同的方式对系统造成影响，硬件、网卡、电源以及其他的硬件组间都存在故障的风险。这些风险可以通过硬件冗余来避免。同时，MongoDB系统也可以在软件层面实现数据冗余性。
日志MongoDB通过预写日志操作以实现存储引擎的快速灾备恢复以及持久性。服务器宕机的情况下，日志系统可以在系统重启后对数据进行恢复。
日志系统的具体表现取决于配置的存储引擎：
l WiredTiger存储引擎能保证在两个检查点之间写操作可以持久性写到到硬盘中。WiredTiger引擎使用检查点实现数据刷入硬盘中，默认情况下，每60秒或者写入数据达到2G时，就会进行一次刷入操作。所以，如果不开启日志属性的话，WiredTiger会丢失60秒以上的写入数据，尽管这些风险可以通过复制集来避免。