翻译或纠错本页面

生产环境指南¶

本篇详细描述了（尤其在生产环境下）影响MongoDB的系统配置。

注解

MongoDB Management Service (MMS) 是一项托管监控服务，该服务收集和聚合诊断数据以直观地表示MongoDB部署的性能和操作。更多信息，请参见 MMS Website 和 MMS documentation。

软件包¶

MongoDB¶

确定你使用的是最新稳定的发行版本。所有的发行版本都可以在 Downloads 页面得到。哪怕你最终选择通过包管理器安装，该页面仍是判定哪个是最新版本的好地方。

在生产中总是使用64位构建版本。用于测试和开发环境的32位版的MongoDB由于不能存储大于2GB的数据不适用于生产部署。更多信息请参见 32-bit limitations。

32位构建版本是为了支持开发机器的使用而存在的。

操作系统¶

MongoDB发行版目前支持Mac OS X，Linux， Windows Server 2008 R2 64位,，Windows 7 （32位和64位）， Windows Vista和Solaris平台。

注解

如果系统的 GNU C Library (glibc)可用，MongoDB将使用该库。MongoDB最低需要 glibc-2.12-1.2.el6 版本的glibc以避免之前版本中的一个已知漏洞。为了更好的效果，请使用至少2.13版本。

并发¶

在之前版本的MongoDB中，所有的写操作争用MongoDB实例中一个唯一的读写锁。从2.2版本开始，（实例中的）每个数据库拥有一个读写锁，该锁使得数据库可以进行并行读，但是该锁给予每个数据库的单一写操作独占权限。更多信息请参见 Concurrency 页面。

日志¶

MongoDB对磁盘 journal 使用 预写式日志技术 以确保MongoDB能在崩溃或其它严重失败之后迅速恢复 write operations。

为了确保 mongod 能够在崩溃之后恢复数据文件并保持数据文件的有效状态，请启用日志。更多信息请参见 Journaling。

网络¶

使用可信赖的网络环境¶

总是在 可信赖的环境 中运行 MongoDB，并通过网络规则阻止所有未知的机器、系统和网络的接入。与任一对网络接入敏感的系统一样，你的MongoDB部署应该只能被需要访问的指定系统访问，比如应用服务器、监控服务和其它MongoDB组件。

注解

默认情况下， authorization 没有开启， mongod 假定这是一个可信赖的环境。当你需要时，你可以开启 security/auth 模式。

更多信息请参见 Security Section 中的文档，尤其是：

对于Windows用户，在Windows上部署MongoDB时可以参考 Windows Server Technet Article on TCP Configuration。

连接池¶

为了避免单个 mongod 或 mongos 实例的连接资源负荷过重，请确保客户端保持持着合理的连接池大小。

数据库命令 connPoolStats 返回打开的到当前数据库的连接数的相关信息，包括连接到分片集群中的 mongos 实例和 mongod 实例的所有连接。

硬件考量¶

MongoDB特意设计为从核心支持硬件，几乎没有对硬件的要求或限制。MongoDB的核心在小端格式的硬件上运行，主要是x86/x86_64处理器。客户端库（例如驱动）可以在大端或小端格式的系统中运行。

硬件要求和限制¶

最高性能的MongoDB部署的硬件具有如下特征：

分配足够的内存和处理器¶

和所有的软件一样，更多的内存和更快的处理器时钟频率对于性能很重要。

一般情况下，数据库不是计算密集型的。正因为如此，增加处理器核数（对性能）会有帮助，但是并不会带来明显的边际收益。

使用固态硬盘（SSDs）¶

MongoDB使用SATA SSD（固态硬盘）的效果很好，并且使用SATA SSD（固态硬盘）有较高的性价比。

在SSD可用并且经济可行的条件下，尽可能地使用SSD。旋转式机械硬盘可以达到高性能，但是固态硬盘执行随机I/O操作的能力与 mongod 的更新模式配合得很好。

商用（SATA接口的）旋转式驱动器常常是一个好的选择，尽管添加更多昂贵的旋转式机械硬盘，随机I/O性能的提升不会很巨大（只有大约2x）。使用固态硬盘或者增加内存在提升I/O吞吐量方面更加有效。

避免远程文件系统¶

远程文件存储会在MongoDB中造成性能问题。更多关于MongoDB和存储的信息请参见 远程文件系统。

MongoDB和NUMA硬件¶

重要

本节关于NUMA的讨论仅适用于拥有多个物理处理器的Linux系统，因此，本节的讨论绝对不会影响那些 mongod 实例运行在其它类UNIX系统、Windows或只有一个物理处理器的Linux系统上的部署。

在非统一内存访问（NUMA）的系统上运行MongoDB会导致许多运行问题，包括剪短时间的低性能和很高的系统进程使用率。

当在NUMA硬件上运行MongoDB时，你应当为MongoDB禁用NUMA并设置交错的内存策略作为替代。

注解

当被部署到基于Linux的系统时，MongoDB2.0及以上版本在启动时会检查这些设置，如果该系统是基于NUMA的，MongoDB将会打印一个警告。

为了禁用NUMA并设置交错的内存策略，使用 numactl 命令并以如下方式启动 mongod ：

numactl --interleave=all /usr/bin/local/mongod

然后，使用如下命令在 proc 设置里禁用 zone reclaim ：

echo 0 > /proc/sys/vm/zone_reclaim_mode

为了完全禁用NUMA，你必须执行这两个操作。更多信息，请参见 Documentation for /proc/sys/vm/*。

参见文章 The MySQL “swap insanity” problem and the effects of NUMA ，它描述了NUMA对数据库的影响。这篇博客文章描述的是NUMA对MySQL的影响，但是对于MongDB来说，问题是类似的。文章介绍了NUMA和它的目标，并阐明了为何这些目标不能与生产环境下的数据库兼容。

硬盘和存储系统¶

交换空间¶

为你的系统指定交换空间。分配存储空间可以避免内存争用的问题并可以防止Linux系统的OOM Killler杀死 mongod。

The method mongod uses to map memory files to memory ensures that the operating system will never store MongoDB data in swap space.

磁盘阵列（RAID）¶

大多数的MongoDB部署应当使用支持RAID-10的硬盘。

RAID-5和RAID-6通常不能提供足够的性能来支持MongoDB的部署。

避免RAID-0和MongoDB的部署。尽管RAID-0提供了良好的写入性能，但它也带来了有限的可用性并且可导致读取操作的性能降低，尤其是在使用亚马逊的EBS卷时。

远程文件系统¶

不推荐和网络文件系统协议（NFS）一起使用MongoDB，因为其某些版本性能不佳。

当把数据文件和日志文件都托管在NFS上时会出现性能问题。如果你把日志放在本地或 iscsi 卷，你可以体验到更好的表现。如果你必须使用NFS，加入如下的NFS选项到你的 /etc/fstab 文件中： bg， nolock，和 noatime。

分离各组件到不同的存储设备¶

为了提高性能，考虑将你的数据库的数据，日志和记录分离到不同的存储设备上，（当然），这取决于你的应用的访问和写入模式。

注解

这会影响你创建快照风格的数据备份的能力，因为这些文件将会在不同的设备和卷上。

虚拟设备的调度¶

为了最佳的性能，通过虚拟机管理程序连接到虚拟机实例的本地块设备应当使用 noop 调度程序。 noop 调度程序允许操作系统将I/O调度推迟到下层的虚拟机管理程序。

架构¶

安全写级别¶

Write concern 描述了MongoDB报告写操作成功时提供的保证。安全写级别的强度决定了保证的等级。当插入，更新和删除（操作）拥有弱安全写级别时，写操作快速返回。在一些失败的例子中，在弱安全写级别下发布的写操作不会被持久化。在强安全写级别下，为了确认写操作,客户端会在给MongoDB发出写操作后等待。

为了更好地处理应用的特殊需求，MongoDB提供了各种不同的安全写级别等级。客户端应当调整安全写级别，以保证最重要的操作对整个MongoDB部署都能成功持久化。对于其它不是那么重要的操作，客户端可以调整安全写级别以保证更快的性能而不是保证对整个部署的持久化。

更多关于如何为你的部署选择一个合适的安全写级别等级的信息，请参见文档 Write Concern。

复制集¶

请参见文档 Replica Set Architectures 对复制集部署的架构考量有个概览。

分片集群¶

请参见文档 Sharded Cluster Production Architecture 对生产环境下推荐的分片集群架构有个概览。

平台¶

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发行版	文件系统	内核版本
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的共享文件夹 不支持 该操作。

虚拟环境的MongoDB¶

本节描述了在一些更常见的虚拟环境中运行MongoDB需要考虑的事情。

对于所有平台，参考 虚拟设备的调度。

EC2¶

MongoDB与EC2是兼容的，不需要特地修改配置即可部署到该环境中。

或者，你可以选择获取一套把MongoDB和亚马孙的Provisioned IOPS一起打包的Amazon Machine Images(AMI)。Provisioned IOPS可以极大地提高MongoDB的性能和易用性。更多信息，请参见 this blog post。

VMWare¶

MongoDB与VMWare是兼容的。由于一些用户在使用VMWare 的内存过量使用功能时遇到过问题，建议禁用该功能。

克隆一个正在运行MongoDB的虚拟机是可行的。您可以使用此功能来启动一个新的虚拟主机并添加为副本集的成员。如果您克隆启用了日志的虚拟机器，克隆快照是有效的。如果您克隆的虚拟机没有使用日志，首先停止 mongod，然后克隆虚拟机，最后，重新启动 mongod。

OpenVZ¶

如VMWare一样，由于OpenVZ对虚拟内存的处理，一些用户在OpenVZ的某些老版本上运行MongoDB时遇到了问题。

这个问题似乎已经在OpenVZ的较新版本得到解决。

性能监控¶

iostat¶

在Linux上，使用 iostat 命令检查磁盘I/O是否是数据库的瓶颈。运行iostat时请指定秒数，以免展示的统计数据隐藏了从服务器启动后经过的时间。

例如，以下命令会每隔一秒展示额外的统计数据和每次展示报表的时间（以MB/s为流量单位）：

iostat -xmt 1

``iostat``中的关键字段：

%util：这对快速查看来说是最有用的字段，它指明了设备/驱动器使用时间的百分比。
avgrq-sz：平均请求大小。该值较小的数字反映了更多的随机IO操作。

bwm-ng¶

bwm-ng 是一个监视网络使用的命令行工具。如果你怀疑是基于网络的瓶颈，你可以使用 bwm-ng 来开始您的诊断过程。

备份¶

要备份您的MongoDB数据库，请参考 MongoDB Backup Methods Overview。

← 导入导出MongoDB数据数据管理 →