Production Notes

在本页面

• MongoDB Binaries

• MongoDB dbPath

• Concurrency

• Data Consistency

• Networking

• Hardware Considerations

• Architecture

• Compression

• Clock Synchronization

• 平台特定注意事项

• Performance Monitoring

• Backups

此页面详细描述了会影响 MongoDB 的系统配置，尤其是在生产环境中运行时。

MongoDB Binaries

Supported Platforms

要在生产环境中运行**，请参考Recommended Platforms以获得 os 建议。

在版本 3.2 中进行了更改：MongoDB 现在可以在所有受支持的平台上使用WiredTiger 存储引擎。

x86_64

平台支持停产通知

ARM64

PPC64LE(MongoDB 企业版)

s390x(MongoDB 企业版)

平台支持停产通知

• s390x 平台不再支持 MongoDB 3.6 和 3.4. 在 s390x 平台上，请升级到 MongoDB 4.0 或更高版本以获得企业支持，或者升级到 MongoDB 4.2 或更高版本以获得社区支持。

Recommended Platforms

尽管 MongoDB 支持多种平台，但建议将以下 os 用于生产环境：

• Amazon Linux

• Debian 8 和 9

• RHEL/CentOS 6、7 和 8

• SLES 12

• Ubuntu LTS 16.04

• Windows Server 2016

使用最新的稳定软件包

确保您具有最新的稳定版本。

所有 MongoDB 版本都可以在Downloads页上找到。 Downloads页面是验证当前稳定版本的好地方，即使您是通过程序包 Management 器进行安装的。

对于其他 MongoDB 产品，请参考MongoDB 下载中心页面或其respective documentation。

MongoDB dbPath

dbPath目录中的文件必须与配置的storage engine相对应。如果dbPath包含由--storageEngine指定的存储引擎以外的存储引擎创建的数据文件，则mongod将不会启动。

mongod必须具有对指定dbPath的读写权限。

Concurrency

MMAPv1

在版本 3.0 中进行了更改：从 MongoDB 3.0 开始，MMAPv1提供了集合级锁定：所有集合都具有唯一的读写器锁，允许多个 Client 端同时修改不同集合中的文档。

对于 2.2 到 2.6 系列的 MongoDB 版本，每个数据库都有一个读写器锁，该锁允许对数据库的并发读取访问，但对每个数据库的单个写操作具有独占访问权限。有关更多信息，请参见Concurrency页。在早期版本的 MongoDB 中，所有写入操作都争用整个mongod实例的单个读写器锁。

WiredTiger

WiredTiger支持读写器同时访问集合中的文档。Client 端可以在进行写操作时读取文档，并且多个线程可以同时修改集合中的不同文档。

Data Consistency

Journaling

MongoDB 使用预先写入日志到磁盘journal。日志记录可确保 MongoDB 可以快速恢复已写入日志的write operations，但在mongod因崩溃或其他严重故障而终止的情况下，无法恢复写入数据文件的write operations。

使日记功能保持启用状态，以确保mongod在崩溃后将能够恢复其数据文件并将数据文件保持在有效状态。有关更多信息，请参见Journaling。

Read Concern

3.2 版中的新功能。

从 MongoDB 3.6 开始，如果写入请求确认，则可以使用因果一致的会话来读取自己的写入。

在 MongoDB 3.6 之前，您必须以{ w: "majority" }写入关注度发出写入操作，然后对读取操作使用"majority"或"linearizable"读取关注度，以确保单个线程可以读取自己的写入。

要使用read concern级别"majority"，副本集必须使用WiredTiger 存储引擎和选举协议版本 1。

从 MongoDB 3.6 开始，默认情况下启用对读取关注"majority"的支持。对于 MongoDB 3.6.1-3.6.x，您可以禁用阅读关注"majority"。有关更多信息，请参见禁用多数阅读关注。

Write Concern

Write concern描述了 MongoDB 向写操作请求的确认级别。写关注点的级别会影响写操作返回的速度。当写操作遇到“弱”写问题时，它们会迅速返回。对于更强的写关注，Client 端必须在发送写操作之后 await，直到 MongoDB 在请求的写关注级别上确认写操作为止。没有足够的写顾虑，写操作对 Client 端来说似乎已经成功，但是在某些服务器故障的情况下可能无法持久。

有关为您的部署选择适当的写关注级别的更多信息，请参见Write Concern文档。

Networking

使用受信任的网络环境

始终在受信任的环境中运行 MongoDB，并且其网络规则会阻止来自所有未知机器，系统和网络的访问。与依赖网络访问的任何敏感系统一样，您的 MongoDB 部署仅应由需要访问的特定系统访问，例如应用程序服务器，监视服务和其他 MongoDB 组件。

有关安全性的其他信息和注意事项，请参阅Security Section中的文档，特别是：

• Security Checklist

• MongoDB 配置强化

• 加强网络基础设施

对于 Windows 用户，在 Windows 上部署 MongoDB 时请考虑Windows Server Technet 上有关 TCP 配置的文章。

禁用 HTTP 接口

在版本 3.6 中进行了更改：MongoDB 3.6 删除了 MongoDB 弃用的 HTTP 接口和 REST API。

MongoDB 的早期版本提供 HTTP 接口来检查服务器的状态，并可以选择运行查询。默认情况下，HTTP 接口是禁用的。不要在生产环境中启用 HTTP 接口。

Management 连接池大小

通过调整连接池大小以适合您的使用情况，避免mongod或mongos实例的连接资源过载。从当前数据库请求的典型数量的 110-115％开始，然后根据需要修改连接池的大小。请参考连接池选项以调整连接池的大小。

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

另请参见分配足够的 RAM 和 CPU。

Hardware Considerations

MongoDB 专门针对商品硬件而设计，几乎没有硬件要求或限制。 MongoDB 的核心组件运行在低端硬件上，主要是 x86/x86_64 处理器。Client 端库(即驱动程序)可以在大小端系统上运行。

分配足够的 RAM 和 CPU

至少要确保每个mongod或mongos实例都可以访问两个真实内核或一个多核物理 CPU。

MMAPv1

由于其并发模型，MMAPv1存储引擎不需要很多 CPU 内核。这样，增加内核数量可以提高性能，但不能提供可观的回报。

增加 MongoDB 可访问的 RAM 数量可能有助于减少页面错误的发生率。

WiredTiger

WiredTiger存储引擎是多线程的，可以利用其他 CPU 内核。具体来说，相对于可用 CPU 数量而言，活动线程(即并发操作)的总数会影响性能：

• 随着并发活动操作数增加到 CPU 数，吞吐量“增加” *。

• 当并发活动操作数超过 CPU 数某个阈值量时，吞吐量减少。

该阈值取决于您的应用程序。您可以通过试验和测量吞吐量来确定应用程序的最佳并发活动操作数。 mongostat的输出在(ar|aw)列中提供有关活动读/写次数的统计信息。

通过 WiredTiger，MongoDB 可以利用 WiredTiger 内部缓存和文件系统缓存。

从 MongoDB 3.4 开始，默认的 WiredTiger 内部缓存大小是以下两者中的较大者：

• 50％(RAM-1 GB)，或

• 256 MB.

默认情况下，WiredTiger 对所有集合使用 Snappy 块压缩，对所有索引使用前缀压缩。压缩默认值是可以在全局级别配置的，也可以在收集和索引创建期间基于每个集合和每个索引进行设置。

WiredTiger 内部缓存中的数据与磁盘格式使用不同的表示形式：

• 文件系统缓存中的数据与磁盘上的格式相同，包括对数据文件进行任何压缩的好处。os 使用文件系统缓存来减少磁盘 I/O。

• 加载到 WiredTiger 内部缓存中的索引的数据表示形式与磁盘上的格式不同，但仍可以利用索引前缀压缩来减少 RAM 使用量。索引前缀压缩对来自索引字段的通用前缀进行重复数据删除。

• WiredTiger 内部缓存中的收集数据未压缩，并且使用与磁盘格式不同的表示形式。块压缩可以节省大量的磁盘存储空间，但是必须对数据进行解压缩才能由服务器进行处理。

通过文件系统缓存，MongoDB 自动使用 WiredTiger 缓存或其他进程未使用的所有可用内存。

要调整 WiredTiger 内部缓存的大小，请参见storage.wiredTiger.engineConfig.cacheSizeGB和--wiredTigerCacheSizeGB。避免将 WiredTiger 内部缓存的大小增加到其默认值以上。

默认的 WiredTiger 内部缓存大小值假定每台计算机只有一个mongod实例。如果一台机器包含多个 MongoDB 实例，则应减小设置以容纳其他mongod实例。

如果您在不能访问系统中所有可用 RAM 的容器(例如lxc，cgroups，Docker 等)中运行mongod，则必须将storage.wiredTiger.engineConfig.cacheSizeGB的值设置为小于该容器中可用 RAM 的值。容器。确切的数量取决于容器中运行的其他进程。参见memLimitMB。

要查看有关缓存和逐出速率的统计信息，请参阅serverStatus命令返回的wiredTiger.cache字段。

压缩和加密

使用加密时，配备 AES-NI 指令集扩展的 CPU 具有明显的性能优势。如果您将 MongoDB Enterprise 和加密存储引擎一起使用，请选择支持 AES-NI 的 CPU，以获得更好的性能。

使用固态磁盘(SSD)

使用 SATA SSD(固态磁盘)，MongoDB 具有良好的结果和良好的性价比。

如果可用且经济实惠，请使用 SSD。旋转磁盘可以实现高性能，但是 SSD 的随机 I/O 操作能力可以与 MMAPv1 的更新模型很好地配合。

商品(SATA)旋转驱动器通常是一个不错的选择，因为更昂贵的旋转驱动器所带来的随机 I/O 性能提升并不那么引人注目(仅为 2 倍)。使用 SSD 或增加 RAM 可能会更有效地提高 I/O 吞吐量。

MongoDB 和 NUMA 硬件

在具有非统一内存访问(NUMA)的系统上运行 MongoDB 可能会导致许多操作问题，包括一段时间内性能下降以及系统进程使用率很高。

在 NUMA 硬件上运行 MongoDB 服务器和 Client 端时，应配置内存交错策略，以便主机以非 NUMA 方式运行。当部署在 Linux(自 2.0 版起)和 Windows(自 2.6 版起)计算机上时，MongoDB 在启动时会检查 NUMA 设置。如果 NUMA 配置可能会降低性能，则 MongoDB 将显示警告。

在 Windows 上配置 NUMA

在 Windows 上，必须通过计算机的 BIOS 启用内存交错。有关详细信息，请查阅系统文档。

在 Linux 上配置 NUMA

在 Linux 上，您必须禁用* zone reclaim *，并确保mongod和mongos实例由numactl启动，numactl通常是通过平台的 init 系统配置的。您必须执行这两项操作，才能正确禁用 NUMA 与 MongoDB 一起使用。

• 使用以下命令之一禁用“区域回收”：

echo 0 | sudo tee /proc/sys/vm/zone_reclaim_mode

sudo sysctl -w vm.zone_reclaim_mode=0

• 确保numactl启动mongod和mongos。通常，这是通过平台的 init 系统配置的。运行以下命令以确定您的平台上正在使用哪个初始化系统：

ps --no-headers -o comm 1

• 如果为“ systemd”，则您的平台使用 systemd 初始化系统，并且您必须*按照下面 systemd 选项卡中的步骤编辑您的 MongoDB 服务文件。

• 如果为“ init”，则您的平台使用* SysV Init 系统，并且您不需要*执行此步骤。 SysV Init 的默认 MongoDB 初始化脚本包括默认情况下通过numactl启动 MongoDB 实例的必要步骤。

• 如果您 Management 自己的初始化脚本(即您没有使用这两个初始化系统中的任何一个)，则必须*按照下面“自定义初始化脚本”标签中的步骤进行操作，以编辑自定义初始化脚本。

sudo cp /lib/systemd/system/mongod.service /etc/systemd/system/

/usr/bin/numactl --interleave=all

ExecStart=/usr/bin/mongod --config /etc/mongod.conf

ExecStart=/usr/bin/numactl --interleave=all /usr/bin/mongod --config /etc/mongod.conf

sudo systemctl daemon-reload

sudo systemctl stop mongod
sudo systemctl start mongod

numactl --interleave=all <path> <options>

numactl --interleave=all /usr/local/bin/mongod -f /etc/mongod.conf

有关更多信息，请参见/ proc/sys/vm/*的文档。

磁盘和存储系统

Swap

为您的系统分配交换空间。分配交换空间可以避免内存争用问题，并且可以防止 Linux 系统上的 OOM Killer 杀死mongod。

对于 MMAPv1 存储引擎，方法mongod用于将文件 Map 到内存可确保 os 永远不会在交换空间中存储 MongoDB 数据。在 Windows 系统上，由于承诺限制，使用 MMAPv1 需要额外的交换空间。有关详细信息，请参见Windows 上的 MongoDB。

对于 WiredTiger 存储引擎，给定足够的内存压力，WiredTiger 可以将数据存储在交换空间中。

RAID

为了在存储层方面获得最佳性能，请使用 RAID-10 支持的磁盘。 RAID-5 和 RAID-6 通常不能提供足够的性能来支持 MongoDB 部署。

Remote Filesystems

使用 MMAPv1 存储引擎时，不建议使用网络文件系统协议(NFS)，因为当数据文件和日记文件都托管在 NFS 上时，您可能会看到性能问题。如果将日志放置在本地或iscsi卷上，则可能会遇到更好的性能。

使用 WiredTiger 存储引擎，如果远程文件系统符合 ISO/IEC 9945-1：1996(POSIX.1)，则 WiredTiger 对象可以存储在远程文件系统上。由于远程文件系统通常比本地文件系统慢，因此使用远程文件系统进行存储可能会降低性能。

如果决定使用 NFS，请将以下 NFS 选项添加到/etc/fstab文件：bg，nolock和noatime。

将组件分离到不同的存储设备上

为了提高性能，请考虑根据应用程序的访问和写入模式将数据库的数据，日志和日志分离到不同的存储设备上。将组件安装为单独的文件系统，并使用符号链接将每个组件的路径 Map 到存储它的设备。

对于 WiredTiger 存储引擎，您还可以将索引存储在其他存储设备上。参见storage.wiredTiger.engineConfig.directoryForIndexes。

Scheduling

虚拟或云托管设备的计划

对于通过虚拟机监控程序连接到虚拟机实例或由云托管提供商托管的本地块设备，Clientos 应使用* noop *调度程序以获得最佳性能。 * noop *调度程序允许 os 将 I/O 调度推迟到基础虚拟机 Management 程序。

物理服务器的调度

对于物理服务器，os 应使用最后期限调度程序。 最后期限调度程序可限制每个请求的最大延迟，并保持良好的磁盘吞吐量，最适合磁盘密集型数据库应用程序。

Architecture

Replica Sets

有关副本集部署的体系结构注意事项的概述，请参见副本集体系结构文档。

Sharded Clusters

有关为生产部署推荐的分片群集体系结构的概述，请参见分片集群生产架构。

Compression

WiredTiger 可以使用snappy或zlib压缩库来压缩收集数据。 snappy提供较低的压缩率，但性能成本较低，而zlib提供较高的压缩率，但性能成本较高。

默认情况下，WiredTiger 使用snappy压缩库。要更改压缩设置，请参见storage.wiredTiger.collectionConfig.blockCompressor。

默认情况下，WiredTiger 在所有索引上使用prefix compression。

Clock Synchronization

MongoDB components保留逻辑时钟以支持与时间有关的操作。使用NTP同步主机时钟可以降低组件之间时钟漂移的风险。组件之间的时钟漂移增加了与时间有关的操作的不正确或异常行为的可能性，如下所示：

• 如果任何给定的 MongoDB 组件的基础系统时钟与同一部署中的其他组件相比偏移了一年或更长时间，则这些成员之间的通信可能变得不可靠或完全停止。

maxAcceptableLogicalClockDriftSecs参数控制组件之间可接受的时钟漂移量。值maxAcceptableLogicalClockDriftSecs较低的群集对时钟漂移的容忍度相应较低。

• 对于具有不同系统时钟的两个群集成员，对于其返回值取决于系统时钟的操作，它们可能返回不同的值，例如Date()。

• 依赖计时的功能在 MongoDB 组件之间的时钟漂移的群集中可能具有不一致或不可预测的行为。

例如，TTL indexes依靠系统时钟来计算何时删除给定的文档。如果两个成员的系统时钟时间不同，则每个成员可以在不同的时间删除 TTL 索引覆盖的给定文档。由于Client 会议和因果一致性保证使用 TTL 索引来控制其寿命，因此时钟漂移可能导致不一致或不可预测的会话超时行为。

使用 Wired Tiger 存储引擎运行低于3.4.6或3.2.17的 MongoDB 的部署需要 NTP 同步，否则时钟漂移可能导致checkpoint hangs。该问题已在 MongoDB 3.4.6+和 MongoDB 3.2.17+中修复，并已在 MongoDB 3.6 的所有发行版中解决。

平台特定注意事项

Linux 上的 MongoDB

内核和文件系统

在 Linux 上的生产环境中运行 MongoDB 时，应将 Linux 内核版本 2.6.36 或更高版本与 XFS 或 EXT4 文件系统一起使用。如果可能的话，请使用 XFS，因为它通常在 MongoDB 中表现更好。

对于WiredTiger 存储引擎，强烈建议对数据承载节点使用 XFS，以避免将 EXT4 与 WiredTiger 一起使用时可能出现的性能问题。

使用MMAPv1 存储引擎，MongoDB 在使用数据库文件之前会对其进行预分配，并且通常会创建大文件。因此，您应该使用 XFS 或 EXT4 文件系统。如果可能的话，请使用 XFS，因为它通常在 MongoDB 中表现更好。

• 通常，如果您使用 XFS 文件系统，请至少使用 Linux 内核的版本2.6.25。

• 如果您使用 EXT4 文件系统，请至少使用 Linux 内核的版本2.6.28。

• 在 Red Hat Enterprise Linux 和 CentOS 上，至少使用 Linux 内核的版本2.6.18-194。

系统 C 库

MongoDB 在 Linux 上使用GNU C 库(glibc)。通常，每个 Linux 发行版都提供该库的经过审查的版本。为了获得最佳结果，请使用此系统提供的版本的最新更新。您可以使用系统的软件包 Management 器来检查是否安装了最新版本。例如：

• 在 RHEL/CentOS 上，以下命令将更新系统提供的 GNU C 库：

sudo yum update glibc

• 在 Ubuntu/Debian 上，以下命令将更新系统提供的 GNU C 库：

sudo apt-get install libc6

目录 fsync()

将 vm.swappiness 设置为 1

“ Swappiness”是 Linux 内核设置，在需要分配从0到100(包括_)的交换时，它会影响虚拟内存 Management 器的行为。

• 设置0告诉内核仅进行交换以避免出现内存不足的问题。

• 设置100指示它主动与磁盘交换。

如果您的主机运行的内核版本是3.5或更高版本，或者是 RHEL/CentOS 内核2.6.32-303或更高版本，则将此值设置为0可能会禁用交换。将此设置为1。

要查看当前的交换级别，请运行：

example@example:$ cat /proc/sys/vm/swappiness

60

要在系统运行时更改可交换性，请运行：

example@example:$ sysctl vm.swappiness=1

要永久更改交换性，请在首选的文本编辑器中编辑/etc/sysctl.conf文件并更改此值：

vm.swappiness = 1

Recommended Configuration

对于 所有 MongoDB 部署：

• 使用网络时间协议(NTP)在主机之间同步时间。这在分片群集中尤其重要。

对于 WiredTiger 和 MMAPv1 存储引擎，请考虑以下建议：

• 关闭atime以获取包含database files的存储卷。

• 根据ulimit参考中的建议，将文件 Descriptors 限制-n和用户进程限制(ulimit)-u设置为 20,000 以上。如果 ulimit 值过低，则会在大量使用时影响 MongoDB，并可能产生错误并导致与 MongoDB 进程的连接失败以及服务丢失。

• 禁用透明大页面。 MongoDB 在正常(4096 字节)的虚拟内存页上表现更好。参见透明的大页面设置。

• 在您的 BIOS 中禁用 NUMA。如果那不可能，请参阅NUMA 硬件上的 MongoDB。

• 如果使用默认的 MongoDB 目录路径或ports 不是 ，请为 MongoDB 配置 SELinux。

请参阅：为 MongoDB 配置 SELinux和为 MongoDB Enterprise 配置 SELinux以获取所需的配置。

对于 WiredTiger 存储引擎：

• 不管存储媒体类型(旋转磁盘，SSD 等)如何，将预读设置设置为 8 至 32.

通常，较高的预读功能通常有利于 SequencesI/O 操作。由于 MongoDB 磁盘访问模式通常是随机的，因此使用较高的预读设置会带来有限的收益或潜在的性能下降。因此，为了获得最佳的 MongoDB 性能，请将预读设置为 8 到 32 之间，除非测试显示以较高的预读值显示出可测量，可重复且可靠的好处。 MongoDB 商业支持可以提供有关备用预读配置的建议和指导。

对于 MMAPv1 存储引擎：

• 确保用于存储数据库文件的块设备的预读设置合适。对于随机访问使用模式，请设置较低的预读值。预读 32(16 kB)通常效果很好。

对于标准块设备，您可以运行sudo blockdev --report获取预读设置，并运行sudo blockdev --setra <value> <device>更改预读设置。有关更多信息，请参阅您的特定 os 手册。 MongoDB 商业支持可以提供有关备用预读配置的建议和指导。

MongoDB 和 TLS/SSL 库

在 Linux 平台上，您可能会在 MongoDB 日志中观察到以下语句之一：

<path to TLS/SSL libs>/libssl.so.<version>: no version information available (required by /usr/bin/mongod)
<path to TLS/SSL libs>/libcrypto.so.<version>: no version information available (required by /usr/bin/mongod)

这些警告表明系统的 TLS/SSL 库与mongod所针对的 TLS/SSL 库不同。通常，这些消息不需要干预。但是，您可以使用以下操作来确定mongod期望的符号版本：

objdump -T <path to mongod>/mongod | grep " SSL_"
objdump -T <path to mongod>/mongod | grep " CRYPTO_"

这些操作将返回类似于以下行之一的输出：

0000000000000000      DF *UND*       0000000000000000  libssl.so.10 SSL_write
0000000000000000      DF *UND*       0000000000000000  OPENSSL_1.0.0 SSL_write

此输出中的最后两个字符串是符号版本和符号名称。将这些值与以下操作返回的值进行比较，以检测符号版本不匹配：

objdump -T <path to TLS/SSL libs>/libssl.so.1*
objdump -T <path to TLS/SSL libs>/libcrypto.so.1*

此过程既不精确也不穷举：libcrypto库中mongod使用的许多符号都不以CRYPTO_开头。

Windows 上的 MongoDB

MongoDB 使用 WiredTiger

对于使用 WiredTiger 存储引擎的 MongoDB 实例，Windows 的性能可与 Linux 的性能媲美。

为 Windows 配置文件系统缓存大小(仅适用于 MongoDB 3.6.0-3.6.5)

对于 MongoDB 3.6.0-3.6.5，请检查 Windows 文件系统缓存限制。上限太高或没有限制会影响性能。具体来说，拥有占用总内存 40％或更多的文件系统缓存会导致内存压力增加和性能下降。使用SetSystemFileCacheSize来限制文件系统缓存可以使用的内存量。

MongoDB 使用 MMAPv1

为 MongoDB 2.6.6 和更高版本安装修补程序

Microsoft 已发布 Windows 7 和 Windows Server 2008 R2 的修补程序KB2731284，该修补程序修复了这些 os 使用内存 Map 文件的错误，该错误会对使用 MMAPv1 存储引擎的 MongoDB 的性能产生不利影响。

安装此修补程序可以在 MongoDB 2.6.6 及更高版本的 2.6 系列(仅使用 MMAPv1)以及在 3.0 及更高版本(使用 MMAPv1 作为存储引擎)上获得显着的性能改进。

为 MMAPv1 配置 Windows 页面文件

配置页面文件，以使最小和最大页面文件大小相等且至少为 32 GB。如果在高峰使用期间希望并发写入许多数据库或集合，请使用此大小的倍数。但是，页面文件的大小不需要超过数据库的最大大小。

由于 Windows 需要足够的空间来容纳在高峰使用期间可写的内存 Map 文件的所有区域，因此无论 Windows 是否需要写入，都需要一个大页面文件。

该页面文件不用于数据库存储，并且在正常的 MongoDB 操作期间不会接收写入。因此，页面文件不会影响性能，但是它必须存在并且必须足够大，以在高峰数据库使用期间容纳 Windows 的承诺规则。

虚拟环境上的 MongoDB

本节描述了在某些更常见的虚拟环境中运行 MongoDB 时的注意事项。

对于所有平台，请考虑Scheduling。

AWS EC2

有两种性能配置需要考虑：

• 用于性能测试或基准测试的可再现性能，以及

• 原始最大性能

要针对两种配置调整 EC2 的性能，您应该：

• 为您的实例启用 AWS Enhanced Networking。并非所有实例类型都支持增强网络。

要了解有关增强网络的更多信息，请参阅AWS documentation。

如果您更担心 EC2 的可重现性能，则还应该：

• 将预置的 IOPS 用于存储，将单独的设备用于日志和数据。请勿使用大多数实例类型上可用的临时(SSD)存储，因为它们的性能会随时变化。 (i系列是一个明显的 exception，但非常昂贵.)

• 禁用 DVFS 和 CPU 省电模式。

• Disable hyperthreading.

• 使用numactl将内存位置绑定到单个套接字。

Azure

使用Premium Storage。 Microsoft Azure 提供两种常规类型的存储：标准存储和高级存储。使用高级存储时，Azure 上的 MongoDB 的性能要优于标准存储。

对于所有使用 Azure 的MMAPv1 MongoDB 部署，您必须**使用* Host Cache Preference * READ/WRITE安装承载mongod实例的dbPath的卷。这适用于使用任何来宾 os 运行 MMAPv1 的所有 Azure 部署。

如果您的卷具有不适当的缓存设置，MongoDB 最终可能会因以下错误而关闭：

[DataFileSync] FlushViewOfFile for <data file> failed with error 1 ...
[DataFileSync] Fatal Assertion 16387

当storage.journal.enabled设置为true时，这些关闭不会产生数据丢失。您可以在此事件发生后的任何时间安全地重新启动mongod。

启用READ/WRITE缓存后，MongoDB 的性能 Feature 可能会发生变化。

默认情况下，Azure 负载平衡器上的 TCP 空闲超时为 240 秒，如果您的 Azure 系统上的 TCP keepalive 大于此值，则它可能会使其静默删除连接。您应该将tcp_keepalive_time设置为 120 以改善此问题。

• 要在 Linux 上查看 keepalive 设置，请使用以下命令之一：

sysctl net.ipv4.tcp_keepalive_time

Or:

cat /proc/sys/net/ipv4/tcp_keepalive_time

该值以秒为单位。

• 要更改tcp_keepalive_time的值，可以使用以下命令之一，以秒为单位提供*<value> *：

sudo sysctl -w net.ipv4.tcp_keepalive_time=<value>

Or:

echo <value> | sudo tee /proc/sys/net/ipv4/tcp_keepalive_time

这些操作不会在系统重新引导后持续存在。要保留设置，请将以下行添加到/etc/sysctl.conf，在几秒钟内提供*<value> *，然后重新启动计算机：

net.ipv4.tcp_keepalive_time = <value>

大于300秒(5 分钟)的 keepalive 值将在mongod和mongos套接字上被覆盖，并设置为300秒。

• 要在 Windows 上查看 keepalive 设置，请发出以下命令：

reg query HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v KeepAliveTime

注册表值默认情况下不存在。如果不存在该值，则使用的系统默认值为7200000毫秒或0x6ddd00(十六进制)。

• 要更改KeepAliveTime的值，请在 Management 员命令提示符中使用以下命令，其中<value>以十六进制表示(例如120000为0x1d4c0)：

reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ /t REG_DWORD /v KeepAliveTime /d <value>

Windows 用户应考虑Windows Server Technet 上关于 KeepAliveTime 的文章，以获取有关在 Windows 系统上为 MongoDB 部署设置 keepalive 的更多信息。大于或等于* 600000 *毫秒(10 分钟)的 keepalive 值将被mongod和mongos忽略。

VMware

MongoDB 与 VMware 兼容。

VMware 支持内存过量使用，您可以在其中为虚拟机分配比物理机可用更多的内存。当内存过量使用时，虚拟机 Management 程序将在虚拟机之间重新分配内存。 VMware 的气球驱动程序(vmmemctl)回收被认为价值最低的页面。

气球驱动程序位于 Client 机 os 内部。气球驱动程序扩展时，可能会导致来宾 os 从来宾应用程序中回收内存，这可能会干扰 MongoDB 的内存 Management 并影响 MongoDB 的性能。

不要禁用气球驱动程序和内存过量使用功能。这可能会导致 Management 程序使用其交换，这将影响性能。而是为运行 MongoDB 的虚拟机 Map 并保留全部内存。这样可以确保在 Management 程序中由于过度使用配置而导致内存压力时，不会在本地 os 中对气球进行充气。

通过设置 VMware 的affinity rules确保虚拟机位于特定的 ESX/ESXi 主机上。如果必须手动将虚拟机迁移到另一个主机，并且虚拟机上的mongod实例是primary，则必须首先step down是主服务器，然后是关闭实例。

遵循vMotion 的网络最佳实践和VMKernel。不遵循最佳实践可能会导致性能问题并影响replica set和sharded cluster高可用性机制。

可以克隆运行 MongoDB 的虚拟机。您可以使用此功能启动新的虚拟主机，以将其添加为副本集的成员。如果克隆启用了日记功能的 VM，则克隆快照将有效。如果不使用日记功能，请首先停止mongod，然后克隆 VM，最后重新启动mongod。

KVM

MongoDB 与 KVM 兼容。

KVM 支持内存过量使用，您可以在其中为虚拟机分配比物理机可用更多的内存。当内存过量使用时，虚拟机 Management 程序将在虚拟机之间重新分配内存。 KVM 的气球驱动程序回收那些被认为价值最低的页面。

气球驱动程序位于 Client 机 os 内部。气球驱动程序扩展后，可能会导致来宾 os 从来宾应用程序中回收内存，这可能会干扰 MongoDB 的内存 Management 并影响 MongoDB 的性能。

不要禁用气球驱动程序和内存过量使用功能。这可能会导致 Management 程序使用其交换，这将影响性能。而是为运行 MongoDB 的虚拟机 Map 并保留全部内存。这样可以确保在 Management 程序中由于过度使用配置而导致内存压力时，不会在本地 os 中对气球进行充气。

Performance Monitoring

iostat

在 Linux 上，使用iostat命令检查磁盘 I/O 是否是数据库的瓶颈。运行 iostat 时，请指定秒数，以避免显示覆盖自服务器启动以来的时间的统计信息。

例如，以下命令将以一秒为间隔显示扩展的统计信息和每个显示的报告的时间，流量以 MB/s 为单位：

iostat -xmt 1

iostat中的关键字段：

• %util：这是用于快速检查的最有用的字段，它指示设备/驱动器使用时间的百分比。

• avgrq-sz：平均请求大小。此值的较小数字反映更多的随机 IO 操作。

bwm-ng

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

Backups

要备份您的 MongoDB 数据库，请参阅MongoDB 备份方法概述。