自管理部署的生产说明

WiredTiger

WiredTiger 存储引擎支持多线程，可以利用额外的 CPU 核心。具体来说，相对于可用 CPU 数量，活动线程（即并发操作）的总数可能会影响性能：

• 吞吐量随着并发活动操作数量增加而增加，最高可达 CPU 数量。

• 当同时活跃的操作数量超过 CPU 数量且超出的数量达到一定阈值时，吞吐量便会降低。

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

借助 WiredTiger，MongoDB 可同时利用 WiredTiger 内部缓存和文件系统缓存。

默认 WiredTiger 内部缓存大小为以下两者中的较大者：

• （RAM 大小 - 1 GB）的 50%，或

• 256 MB.

例如，在总 RAM 为 4GB 的系统上，WiredTiger 缓存使用 1.5GB RAM (0.5 * (4 GB - 1 GB) = 1.5 GB)。相反，在总 RAM 为 1.25GB 的系统上，WiredTiger 为 WiredTiger 缓存分配了 256 MB，因为这大于总 RAM 的一半减去 1 GB (0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB)。

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

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

• 文件系统缓存中的数据与磁盘上的数据格式相同，并且同样拥有数据文件压缩带来的好处。操作系统使用文件系统缓存来减少磁盘 I/O。

• WiredTiger 内部缓存中加载的索引具有与磁盘上格式不同的数据表示形式，但仍可利用索引前缀压缩来减少 RAM 使用量。索引前缀压缩会对被索引字段中的常用前缀去重。

• WiredTiger 内部缓存中的集合数据未压缩，并使用与磁盘上格式不同的表示形式。区块压缩可大幅节省磁盘上存储空间，但数据必须解压缩才能由服务器操作。

借助文件系统缓存，MongoDB 会自动使用 WiredTiger 缓存或其他进程未使用的所有空闲内存。

如需调整 WiredTiger 内部缓存大小，请参阅 storage.wiredTiger.engineConfig.cacheSizeGB 和 --wiredTigerCacheSizeGB。避免将 WiredTiger 内部缓存大小增加到超过其默认值。

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

如果您在某一容器（例如，lxc、cgroups、Docker 等）中运行 mongod，而这一容器无权访问系统中的全部可用 RAM，请将 storage.wiredTiger.engineConfig.cacheSizeGB 的值设置为小于容器中可用 RAM 数量的值。确切的数量取决于容器中运行的其他进程。请参阅 memLimitMB。

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

压缩和加密

使用加密时，配备 AES-NI 指令集扩展的 CPU 表现出显著的性能优势。如果您使用的是带有加密存储引擎的 MongoDB Enterprise，请选择支持 AES-NI 的 CPU 以获得更好的性能。

在 Windows 上配置 NUMA

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

在 Linux 上配置 NUMA

在 Linux 上，必须禁用区域回收，并确保您的 mongod 和 mongos 实例由 numactl 启动，这通常是通过平台的初始化系统配置的。您必须执行这两个操作以禁止将 NUMA 用于 MongoDB。

1. 使用以下命令禁用区域回收：

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

   sudo sysctl -w vm.zone_reclaim_mode=0

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

   ps --no-headers -o comm 1

   • 如果为 systemd，则您的平台使用 systemd init 系统，并且您必须 按照下面的 systemd 标签页中的步骤来编辑 MongoDB 服务文件。

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

   • 如果您管理自己的初始化脚本（即不使用这些初始化系统中的任何一个），则必须按照下面 Custom init scripts（自定义初始化脚本）选项卡中的步骤来编辑您的自定义初始化脚本。

     
     
   systemd

   自定义初始化脚本

   您必须使用 numactl 启动每个 mongod 实例，包括所有配置服务器、mongos 实例和客户端。为每个实例编辑默认的 systemd 服务文件，如下所示：

   1. 复制默认的 MongoDB 服务文件：

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

   2. 编辑 /etc/systemd/system/mongod.service 文件，并将 ExecStart 语句更新为以下方内容开头：

      /usr/bin/numactl --interleave=all

      例子

      如果您现有的 ExecStart 语句如下：

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

      将该语句更新为：

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

   3. 将更改应用于 systemd：

      sudo systemctl daemon-reload

   4. 重新启动任何正在运行的 mongod 实例：

      sudo systemctl stop mongod
      sudo systemctl start mongod

   5. 如果适用，对任何 mongos 实例重复上述步骤。

   您必须使用 numactl 启动每个 mongod 实例，包括所有配置服务器、mongos 实例和客户端。

   1. 如果尚未安装，请为您的平台安装 numactl。有关安装 numactl 软件包的信息，请参阅操作系统的文档。

   2. 配置每个自定义初始化脚本，通过 numactl 启动每个 MongoDB 实例：

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

      其中 <path> 是要启动的程序的路径，<options> 是要传递给该程序的任何可选参数。

      例子

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

请参阅 /proc/sys/vm/* 文档，了解详情。

Swap

在可避免交换或将交换保持在最低限度的情况下，MongoDB 性能最佳，因为从交换中检索数据总是比在 RAM 中访问数据慢。但是，如果托管 MongoDB 的系统耗尽 RAM，交换功能则可阻止 Linux OOM Killer 终止 mongod 进程。

一般来说，您应选择以下交换策略之一：

1. 在您的系统上分配交换空间，并将内核配置为仅允许在高内存负载下进行交换，或是

2. 请勿在系统上分配交换空间，并将内核配置为完全禁用交换

请参阅设置 vm.swappiness，了解在 Linux 系统上按照这些指南配置交换的说明。

RAID

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

远程文件系统 (NFS)

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

如果决定使用 NFS，请将以下 NFS 选项添加到 /etc/fstab 文件中：

• bg

• hard

• nolock

• noatime

• nointr

根据您的内核版本，其中一些值可能已设置为默认值。有关更多信息，请参阅您的平台文档。

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

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

对于 WiredTiger 存储引擎，您还可在其他存储设备上存储这些索引。请参阅 storage.wiredTiger.engineConfig.directoryForIndexes。

调度

内核和文件系统

在 Linux 上的生产环境中运行 MongoDB 时，应使用Linux kernel 2.6.36 版本或更高版本，使用 XFS 或 EXT4 文件系统。尽可能使用 XFS，因为它通常在 MongoDB 中表现更好。

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

• 一般来说，如果您使用 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 发行版都提供自己的经过审查的 C 库版本。为获得最佳结果，请使用此系统提供版本可用的最新更新。您可以使用系统的软件包管理器来检查是否已安装最新版本。例如：

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

  sudo yum update glibc

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

  sudo apt-get install libc6

fsync() 用于目录

将 vm.swappiness 设置为 1 或 0

“Swappiness”是一个影响虚拟内存管理器行为的 Linux 内核设置。vm.swappiness 设置范围从 0 到 100：值越大，它就越倾向于将内存页面交换到磁盘，而不是从 RAM 中删除页面。

• 0 的设置完全禁用交换 [8]。

• 设置为 1 允许内核仅进行交换以避免内存不足问题。

• 设为 60 可指示内核频繁交换到磁盘，也是众多 Linux 发行版上的默认值。

• 设置为 100 将通知内核主动交换到磁盘。

在可以避免交换或将交换保持在最低限度的情况下，MongoDB 性能最佳。因此，您应根据应用程序需求和集群配置，将 vm.swappiness 设置为 1 或 0。

• 要检查系统上的当前交换设置，请运行：

  cat /proc/sys/vm/swappiness

• 要更改系统上的交换状态，请执行以下操作：

  1. 编辑 /etc/sysctl.conf 文件并添加以下行：

     vm.swappiness = 1

  2. 运行如下命令以应用设置：

     sudo sysctl -p

建议配置

对于所有 MongoDB 部署：

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

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

• 关闭包含数据库文件的存储卷的 atime。

• 根据 ulimit 参考中的建议，调整平台的 ulimit 设置。当重度使用时，较低的 ulimit 值会对 MongoDB 产生负面影响，并可能导致与 MongoDB 进程的连接失败和服务丢失。

  注意

  如果打开文件数的 ulimit 值低于 64000，MongoDB 会生成初创企业警告。

• 如果您正在运行 MongoDB 8.0，请启用透明大页面。

  • 如果您正在运行 MongoDB 7.0 或更早版本，请禁用透明大页面。在早期版本中，MongoDB 在使用典型（4096 字节）虚拟内存页面时性能更好。

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

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

  注意

  如果使用 SELinux，任何需要服务器端 JavaScript 的 MongoDB 操作都会导致“segfault”错误。禁用 JavaScript 的服务器端执行描述了如何禁用服务器端 JavaScript 的执行。

对于 WiredTiger 存储引擎：

• 无论存储介质类型（旋转磁盘、SSD 等）为何，均应将预读大小设为 8 到 32 之间。

  更高的预读通常有利于顺序 I/O 操作。由于 MongoDB 磁盘访问模式通常是随机的，因此使用更高的预读设置的好处有限，或者可能会导致性能下降。因此，除非测试表明更高的预读值具有可测量、可重复且可靠的优势，否则为了获得最佳的 MongoDB 性能，请将预读值设置在 8 到 32 之间。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_ 开头。

AWS EC2

可考虑两种性能配置：

• 性能测试或基准测试的可重现性能，以及

• 原始最高性能

要为任一配置在 EC2 上调优性能，您应该：

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

  请参阅 AWS 文档，详细了解增强联网。

• 将 tcp_keepalive_time 设置为 120。

如果您更关注 EC2 上的可重现性能，则还应该：

• 将预配 IOPS 用于存储，并使用单独的设备存储日志和数据。请勿使用为大多数实例类型提供的临时 (SSD) 存储，因为它们的性能会动态变化。（i 系列虽不在此列，但非常昂贵。）

• 禁用 DVFS 和 CPU 省电模式。

  提示

  另请参阅：

  Amazon 关于处理器状态控制的文档

• 禁用超线程。

  提示

  另请参阅：

  关于禁用超线程的 Amazon 博客文章 。

• 使用 numactl 将内存局部性绑定到单个套接字。

AZURE

使用高级存储。Microsoft Azure 提供两种通用存储类型：标准存储和高级存储。相比标准存储，Azure 上的 MongoDB 使用高级存储时性能更好。

默认情况下，Azure 负载均衡器上的 TCP 空闲超时为 240 秒，而一旦 Azure 系统上的 TCP keepalive 大于该值，就可能导致该负载均衡器以静默方式断开连接。您应该将 tcp_keepalive_time 设置为 120 以改善此问题。

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

  sysctl net.ipv4.tcp_keepalive_time

  或者：

  cat /proc/sys/net/ipv4/tcp_keepalive_time

  该值以秒为单位。

  注意

  尽管该设置名称包含 ipv4，但 tcp_keepalive_time 值会同时应用于 IPv4 和 IPv6。

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

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

  或者：

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

  这些操作不会在系统重启后持续存在。要保留该设置，请将以下行添加到 /etc/sysctl.conf，提供以秒为单位的 <value>，然后重启计算机：

  net.ipv4.tcp_keepalive_time = <value>

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

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

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

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

  
  

• 要更改 KeepAliveTime 值，请在管理员 Command Prompt 中使用以下命令，其中 <value> 以十六进制表示（例如120000 表示为 0x1d4c0）：

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

  Windows 用户应查看有关 KeepAliveTime 的 Windows Server Technet 文章，了解有关在 Windows 系统上为 MongoDB 部署设置 keepalive 的更多信息。大于或等于 600000 毫秒（10 分钟）的 keepalive 值将被 mongod 和 mongos 忽略。

VMware

MongoDB 与 VMware 兼容。

VMware 支持内存复用，因而可为虚拟机分配比物理机可用内存更多的内存。当内存超量时，虚拟机监控程序会在各虚拟机之间重新分配内存。VMware 的气球驱动程序 (vmmemctl) 会回收被视为价值最低的页面。

气球驱动程序驻留在客户机操作系统中。在某些配置下，当气球驱动程序扩展时，它可能会干扰 MongoDB 的内存管理并影响 MongoDB 的性能。

为了防止气球驱动程序和内存过量承诺功能对性能产生负面影响，请为运行 MongoDB 的虚拟机保留全部内存量。为虚拟机预留适当数量的内存，可以防止本地操作系统中的气球在管理程序存在内存压力时膨胀。

即使气球驱动程序和内存过量使用功能在某些配置下可能对 MongoDB 性能产生负面影响，也不要禁用这些功能。如果禁用这些功能，虚拟机管理程序可能会使用其交换空间来满足内存请求，从而对性能产生负面影响。

设置 VMware 的关联性规则，确保将虚拟机保留在特定 ESX/ESXi 主机上。如果必须手动将虚拟机迁移到另一台主机，并且虚拟机上的 mongod 实例是主实例，则必须先 step down 主实例，然后再 shut down the instance。

请遵循 vMotion 和 VMKernel 的联网最佳实践。不遵循最佳实践可能导致性能问题，并影响副本集和分片集群的高可用性机制。

您可以克隆运行 MongoDB 的虚拟机。您可以使用此功能部署新的虚拟主机，将其添加为副本集的成员。

KVM

MongoDB 与 KVM 兼容。

KVM 支持内存复用，因而可以为虚拟机分配比物理机可用内存更多的内存。当内存超量时，虚拟机监控程序会在各虚拟机之间重新分配内存。KVM 的气球驱动程序会回收被视为价值最低的页面。

气球驱动程序驻留在客户机操作系统中。在某些配置下，当气球驱动程序扩展时，它可能会干扰 MongoDB 的内存管理并影响 MongoDB 的性能。

为了防止气球驱动程序和内存过量承诺功能对性能产生负面影响，请为运行 MongoDB 的虚拟机保留全部内存量。为虚拟机预留适当数量的内存，可以防止本地操作系统中的气球在管理程序存在内存压力时膨胀。

即使气球驱动程序和内存过量使用功能在某些配置下可能对 MongoDB 性能产生负面影响，也不要禁用这些功能。如果禁用这些功能，虚拟机管理程序可能会使用其交换空间来满足内存请求，从而对性能产生负面影响。