Production Notes生产说明

WiredTiger

The WiredTiger storage engine is multithreaded and can take advantage of additional CPU cores. WiredTiger存储引擎是多线程的，可以利用额外的CPU内核。Specifically, the total number of active threads (i.e. concurrent operations) relative to the number of available CPUs can impact performance:具体来说，活动线程的总数（即并发操作）相对于可用CPU的数量会影响性能：

• Throughput increases as the number of concurrent active operations increases up to the number of CPUs.吞吐量随着并发活动操作的数量增加到CPU的数量而增加。
• Throughput decreases as the number of concurrent active operations exceeds the number of CPUs by some threshold amount.当并发活动操作的数量超过CPU的数量某个阈值时，吞吐量会降低。

The threshold depends on your application. 阈值取决于您的应用程序。You can determine the optimum number of concurrent active operations for your application by experimenting and measuring throughput. 您可以通过试验和测量吞吐量来确定应用程序的最佳并发活动操作数。The output from mongostat provides statistics on the number of active reads/writes in the (ar|aw) column.mongostat的输出提供了（ar|aw）列中活动读/写次数的统计信息。

With WiredTiger, MongoDB utilizes both the WiredTiger internal cache and the filesystem cache.有了WiredTiger，MongoDB既利用了WiredTinger内部缓存，也利用了文件系统缓存。

Starting in MongoDB 3.4, the default WiredTiger internal cache size is the larger of either:从MongoDB 3.4开始，默认的WiredTiger内部缓存大小是以下两者中较大的一个：

• 50% of (RAM - 1 GB), or
• 256 MB.

For example, on a system with a total of 4GB of RAM the WiredTiger cache will use 1.5GB of RAM (0.5 * (4 GB - 1 GB) = 1.5 GB). 例如，在总内存为4GB的系统上，WiredTiger缓存将使用1.5GB的RAM（0.5 * (4 GB - 1 GB) = 1.5 GB）。Conversely, a system with a total of 1.25 GB of RAM will allocate 256 MB to the WiredTiger cache because that is more than half of the total RAM minus one gigabyte (0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB).相反，总RAM为1.25 GB的系统将为WiredTiger缓存分配256 MB，因为这超过了总RAM的一半减去1 GB（0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB）。

By default, WiredTiger uses Snappy block compression for all collections and prefix compression for all indexes. 默认情况下，WiredTiger对所有集合使用Snappy块压缩，对所有索引使用前缀压缩。Compression defaults are configurable at a global level and can also be set on a per-collection and per-index basis during collection and index creation.压缩默认值可以在全局级别进行配置，也可以在集合和索引创建期间按每个集合和每个索引进行设置。

Different representations are used for data in the WiredTiger internal cache versus the on-disk format:WiredTiger内部缓存中的数据与磁盘上的格式使用不同的表示形式：

• Data in the filesystem cache is the same as the on-disk format, including benefits of any compression for data files. 文件系统缓存中的数据与磁盘上的格式相同，包括对数据文件进行任何压缩的好处。The filesystem cache is used by the operating system to reduce disk I/O.操作系统使用文件系统缓存来减少磁盘I/O。
• Indexes loaded in the WiredTiger internal cache have a different data representation to the on-disk format, but can still take advantage of index prefix compression to reduce RAM usage. WiredTiger内部缓存中加载的索引具有与磁盘上格式不同的数据表示形式，但仍然可以利用索引前缀压缩来减少RAM的使用。Index prefix compression deduplicates common prefixes from indexed fields.索引前缀压缩从索引字段中消除常见前缀的重复。
• Collection data in the WiredTiger internal cache is uncompressed and uses a different representation from the on-disk format. WiredTiger内部缓存中的采集数据未压缩，使用不同于磁盘格式的表示形式。Block compression can provide significant on-disk storage savings, but data must be uncompressed to be manipulated by the server.块压缩可以显著节省磁盘上的存储空间，但数据必须经过压缩才能由服务器操作。

Via the filesystem cache, MongoDB automatically uses all free memory that is not used by the WiredTiger cache or by other processes.通过文件系统缓存，MongoDB自动使用WiredTiger缓存或其他进程未使用的所有可用内存。

To adjust the size of the WiredTiger internal cache, see storage.wiredTiger.engineConfig.cacheSizeGB and --wiredTigerCacheSizeGB. Avoid increasing the WiredTiger internal cache size above its default value.要调整WiredTiger内部缓存的大小，请参阅storage.wiredTiger.engineConfig.cacheSizeGB和--wiredTigerCacheSizeGB。避免将WiredTiger内部缓存大小增加到其默认值以上。

The default WiredTiger internal cache size value assumes that there is a single mongod instance per machine. 默认的WiredTiger内部缓存大小值假定每台机器有一个mongod实例。If a single machine contains multiple MongoDB instances, then you should decrease the setting to accommodate the other mongod instances.如果一台机器包含多个MongoDB实例，那么应该减少设置以容纳其他mongod实例。

If you run mongod in a container (e.g. lxc, cgroups, Docker, etc.) that does not have access to all of the RAM available in a system, you must set storage.wiredTiger.engineConfig.cacheSizeGB to a value less than the amount of RAM available in the container. 如果在无法访问系统中所有可用RAM的容器（例如lxc、cgroups、Docker等）中运行mongod，则必须将storage.wiredTiger.engineConfig.cacheSizeGB设置为小于容器中可用RAM量的值。The exact amount depends on the other processes running in the container. See memLimitMB.确切的数量取决于容器中运行的其他进程。请参阅memLimitMB。

To view statistics on the cache and eviction rate, see the wiredTiger.cache field returned from the serverStatus command.要查看缓存和逐出率的统计信息，请参阅serverStatus命令返回的wiredTiger.cache字段。

Compression and Encryption压缩和加密

When using encryption, CPUs equipped with AES-NI instruction-set extensions show significant performance advantages. 当使用加密时，配备AES-NI指令集扩展的CPU显示出显著的性能优势。If you are using MongoDB Enterprise with the Encrypted Storage Engine, choose a CPU that supports AES-NI for better performance.如果您将MongoDB Enterprise与加密存储引擎一起使用，请选择支持AES-NI的CPU以获得更好的性能。

Configuring NUMA on Windows在Windows上配置NUMA

On Windows, memory interleaving must be enabled through the machine's BIOS. Consult your system documentation for details.在Windows上，必须通过机器的BIOS启用内存交错。有关详细信息，请参阅系统文档。

Configuring NUMA on Linux在Linux上配置NUMA

On Linux, you must disable zone reclaim and also ensure that your mongod and mongos instances are started by numactl, which is generally configured through your platform's init system. 在Linux上，您必须禁用区域回收，并确保您的mongod和mongos实例由numactl启动，numactl通常通过平台的init系统进行配置。You must perform both of these operations to properly disable NUMA for use with MongoDB.您必须执行这两个操作才能正确地禁用NUMA以便与MongoDB一起使用。

1. Disable zone reclaim with one of the following commands:使用以下命令之一禁用区域回收：

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

   sudo sysctl -w vm.zone_reclaim_mode=0

2. Ensure that mongod and mongos are started by numactl. This is generally configured through your platform's init system. 确保mongod和mongos是由numactl启动的。这通常是通过平台的init系统进行配置的。Run the following command to determine which init system is in use on your platform:运行以下命令以确定平台上正在使用哪个init系统：

   ps --no-headers -o comm 1

   • If "systemd", your platform uses the systemd init system, and you must follow the steps in the systemd tab below to edit your MongoDB service file(s).如果是“systemd”，则您的平台使用systemd-init系统，您必须按照下面systemd选项卡中的步骤编辑MongoDB服务文件。
   • If "init", your platform uses the SysV Init system, and you do not need to perform this step. 如果“init”，则您的平台使用SysV init系统，并且您不需要执行此步骤。The default MongoDB init script for SysV Init includes the necessary steps to start MongoDB instances via numactl by default.SysV init的默认MongoDB init脚本包括默认情况下通过numactl启动MongoDB实例的必要步骤。
   • If you manage your own init scripts (i.e. you are not using either of these init systems), you must follow the steps in the Custom init scripts tab below to edit your custom init script(s).如果您管理自己的init脚本（即，您没有使用这两个init系统中的任何一个），则必须按照下面的Custom init scripts选项卡中的步骤编辑您的自定义init脚本。
   systemdCustom init scripts

   You must use numactl to start each of your mongod instances, including all config servers, mongos instances, and clients. Edit the default systemd service file for each as follows:您必须使用numactl来启动每个mongod实例，包括所有配置服务器、mongos实例和客户端。按如下方式编辑每个的默认systemd服务文件：

   1. Copy the default MongoDB service file:复制默认的MongoDB服务文件：

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

   2. Edit the /etc/systemd/system/mongod.service file, and update the ExecStart statement to begin with:编辑/etc/systemd/system/mongod.service文件，并更新ExecStart语句，使其以以下开头：

      /usr/bin/numactl --interleave=all

      Example

      If your existing ExecStart statement reads:如果现有的ExecStart语句为：

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

      Update that statement to read:将该声明更新为：

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

   3. Apply the change to systemd:将更改应用于systemd：

      sudo systemctl daemon-reload

   4. Restart any running mongod instances:重新启动任何正在运行的mongod实例：

      sudo systemctl stop mongod
      sudo systemctl start mongod

   5. If applicable, repeat these steps for any mongos instances.如果适用，请对任何mongos实例重复这些步骤。

   You must use numactl to start each of your mongod instances, including all config servers, mongos instances, and clients.您必须使用numactl来启动每个mongod实例，包括所有配置服务器、mongos实例和客户端。

   1. Install numactl for your platform if not already installed. Refer to the documentation for your operating system for information on installing the numactl package.如果尚未安装，请为您的平台安装numactl。有关安装numactl软件包的信息，请参阅操作系统的文档。

   2. Configure each of your custom init scripts to start each MongoDB instance via numactl:配置每个自定义init脚本，通过numactl启动每个MongoDB实例：

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

      Where <path> is the path to the program you are starting and <options> are any optional arguments to pass to that program.其中<path>是要启动的程序的路径，<options>是要传递给该程序的任何可选参数。

      Example

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

For more information, see the Documentation for /proc/sys/vm/*.有关更多信息，请参阅Documentation for /proc/sys/vm/*的文档。

Swap

MongoDB performs best where swapping can be avoided or kept to a minimum, as retrieving data from swap will always be slower than accessing data in RAM. MongoDB在可以避免或尽量减少交换的地方表现最好，因为从交换中检索数据总是比访问RAM中的数据慢。However, if the system hosting MongoDB runs out of RAM, swapping can prevent the Linux OOM Killer from terminating the mongod process.然而，如果托管MongoDB的系统内存不足，交换可以阻止Linux OOM Killer终止mongod进程。

Generally, you should choose one of the following swap strategies:通常，您应该选择以下交换策略之一：

1. Assign swap space on your system, and configure the kernel to only permit swapping under high memory load, or在系统上分配交换空间，并将内核配置为只允许在高内存负载下进行交换，或者
2. Do not assign swap space on your system, and configure the kernel to disable swapping entirely不要在系统上分配交换空间，并将内核配置为完全禁用交换

See Set vm.swappiness for instructions on configuring swap on your Linux system following these guidelines.请参阅设置vms.wappiness，以获取有关按照这些准则在Linux系统上配置交换的说明。

RAID

For optimal performance in terms of the storage layer, use disks backed by RAID-10. RAID-5 and RAID-6 do not typically provide sufficient performance to support a MongoDB deployment.为了在存储层方面获得最佳性能，请使用由RAID-10支持的磁盘。RAID-5和RAID-6通常不能提供足够的性能来支持MongoDB部署。

Remote Filesystems (NFS)远程文件系统（NFS）

With the WiredTiger storage engine, WiredTiger objects may be stored on remote file systems if the remote file system conforms to ISO/IEC 9945-1:1996 (POSIX.1). 使用WiredTiger存储引擎，如果远程文件系统符合ISO/IEC 9945-1:1996(POSIX.1），则WiredTige对象可以存储在远程文件系统上。Because remote file systems are often slower than local file systems, using a remote file system for storage may degrade performance.由于远程文件系统通常比本地文件系统慢，因此使用远程文件系统进行存储可能会降低性能。

If you decide to use NFS, add the following NFS options to your /etc/fstab file:如果您决定使用NFS，请将以下NFS选项添加到/etc/fstab文件中：

• bg
• hard
• nolock
• noatime
• nointr

Depending on your kernel version, some of these values may already be set as the default. Consult your platform's documentation for more information.根据您的内核版本，其中一些值可能已经设置为默认值。有关详细信息，请参阅您的平台文档。

Separate Components onto Different Storage Devices将组件分离到不同的存储设备上

For improved performance, consider separating your database's data, journal, and logs onto different storage devices, based on your application's access and write pattern. 为了提高性能，请考虑根据应用程序的访问和写入模式，将数据库的数据、日志和日志分离到不同的存储设备上。Mount the components as separate filesystems and use symbolic links to map each component's path to the device storing it.将组件装载为单独的文件系统，并使用符号链接将每个组件的路径映射到存储它的设备。

For the WiredTiger storage engine, you can also store the indexes on a different storage device. 对于WiredTiger存储引擎，您还可以将索引存储在不同的存储设备上。See storage.wiredTiger.engineConfig.directoryForIndexes.请参阅storage.wiredTiger.engineConfig.directoryForIndexes。

Scheduling日程安排

Kernel and File Systems内核和文件系统

When running MongoDB in production on Linux, you should use Linux kernel version 2.6.36 or later, with either the XFS or EXT4 filesystem. 当在Linux上的生产环境中运行MongoDB时，您应该使用Linux内核2.6.36或更高版本，以及XFS或EXT4文件系统。If possible, use XFS as it generally performs better with MongoDB.如果可能的话，使用XFS，因为它通常在MongoDB中表现更好。

With the WiredTiger storage engine, using XFS is strongly recommended for data bearing nodes to avoid performance issues that may occur when using EXT4 with WiredTiger.对于WiredTiger存储引擎，强烈建议数据承载节点使用XFS，以避免将EXT4与WiredTigeer一起使用时可能出现的性能问题。

• In general, if you use the XFS file system, use at least version 2.6.25 of the Linux Kernel.通常，如果使用XFS文件系统，则至少要使用2.6.25版本的Linux内核。
• If you use the EXT4 file system, use at least version 2.6.28 of the Linux Kernel.如果使用EXT4文件系统，请至少使用2.6.28版本的Linux内核。
• On Red Hat Enterprise Linux and CentOS, use at least version 2.6.18-194 of the Linux kernel.在Red Hat Enterprise Linux和CentOS上，请至少使用2.6.18-194版本的Linux内核。

System C LibrarySystem C库

MongoDB uses the GNU C Library (glibc) on Linux. MongoDB在Linux上使用GNU C库（glibc）。Generally, each Linux distro provides its own vetted version of this library. 一般来说，每个Linux发行版都提供这个库的经过审查的版本。For best results, use the latest update available for this system-provided version. 为了获得最佳效果，请使用此系统提供的版本的最新更新。You can check whether you have the latest version installed by using your system's package manager. 您可以使用系统的软件包管理器检查是否安装了最新版本。For example:例如：

• On RHEL / CentOS, the following command updates the system-provided GNU C Library:在RHEL/CNTOS上，以下命令更新系统提供的GNU C库：

  sudo yum update glibc

• On Ubuntu / Debian, the following command updates the system-provided GNU C Library:在Ubuntu/Debian上，以下命令更新系统提供的GNU C库：

  sudo apt-get install libc6

fsync() on Directories关于目录

Set vm.swappiness to 1 or 0

“Swappiness” is a Linux kernel setting that influences the behavior of the Virtual Memory manager. “Swappiness”是影响虚拟内存管理器行为的Linux内核设置。The vm.swappiness setting ranges from 0 to 100: the higher the value, the more strongly it prefers swapping memory pages to disk over dropping pages from RAM.

• A setting of 0 disables swapping entirely [7].
• A setting of 1 permits the kernel to swap only to avoid out-of-memory problems.
• A setting of 60 tells the kernel to swap to disk often, and is the default value on many Linux distributions.
• A setting of 100 tells the kernel to swap aggressively to disk.

MongoDB performs best where swapping can be avoided or kept to a minimum. As such you should set vm.swappiness to either 1 or 0 depending on your application needs and cluster configuration.MongoDB在可以避免或尽量减少交换的地方表现最好。因此，您应该根据应用程序需求和集群配置将vm.swappiness设置为1或0。

• To check the current swappiness setting on your system, run:要检查系统上的当前摇摆度设置，请运行：

  cat /proc/sys/vm/swappiness

• To change swappiness on your system:要更改系统的时髦度，请执行以下操作：
  1. Edit the /etc/sysctl.conf file and add the following line:编辑/etc/sysctl.conf文件并添加以下行：

     vm.swappiness = 1

  2. Run the following command to apply the setting:运行以下命令以应用设置：

     sudo sysctl -p

Recommended Configuration推荐配置

For all MongoDB deployments:对于所有MongoDB部署：

• Use the Network Time Protocol (NTP) to synchronize time among your hosts. 使用网络时间协议（NTP）在主机之间同步时间。This is especially important in sharded clusters.这在分片集群中尤为重要。

For the WiredTiger storage engines, consider the following recommendations:

• Turn off atime for the storage volume containing the database files.
• Adjust the ulimit settings for your platform according to the recommendations in the ulimit reference. Low ulimit values will negatively affect MongoDB when under heavy use and can lead to failed connections to MongoDB processes and loss of service.
  Note

  Starting in MongoDB 4.4, a startup error is generated if the ulimit value for number of open files is under 64000. 从MongoDB 4.4开始，如果打开文件数的ulimit值低于64000，则会生成启动错误。

• Disable Transparent Huge Pages. MongoDB performs better with normal (4096 bytes) virtual memory pages. 禁用透明大页面。MongoDB在使用普通（4096字节）虚拟内存页面时表现更好。See Transparent Huge Pages Settings.请参阅透明大页面设置。
• Disable NUMA in your BIOS. If that is not possible, see MongoDB on NUMA Hardware.在BIOS中禁用NUMA。如果这不可能，请参阅NUMA硬件上的MongoDB。
• Configure SELinux for MongoDB if you are not using the default MongoDB directory paths or ports.
  Note

  If you are using SELinux, any MongoDB operation that requires server-side JavaScript will result in segfault errors. Disable Server-Side Execution of JavaScript describes how to disable execution of server-side JavaScript.

For the WiredTiger storage engine:

• Set the readahead setting between 8 and 32 regardless of storage media type (spinning disk, SSD, etc.).将预读设置设置在8和32之间，而不考虑存储介质类型（旋转磁盘、SSD等）。

  Higher readahead commonly benefits sequential I/O operations. 更高的预读通常有利于顺序I/O操作。Since MongoDB disk access patterns are generally random, using higher readahead settings provides limited benefit or potential performance degradation. 由于MongoDB磁盘访问模式通常是随机的，因此使用更高的预读设置提供的好处有限或潜在的性能下降。As such, for optimal MongoDB performance, set readahead between 8 and 32, unless testing shows a measurable, repeatable, and reliable benefit in a higher readahead value. 因此，为了获得最佳的MongoDB性能，请将预读设置在8到32之间，除非测试显示预读值较高会带来可衡量、可重复和可靠的好处。MongoDB commercial support can provide advice and guidance on alternate readahead configurations.MongoDB的商业支持可以为备用预读配置提供建议和指导。

MongoDB and TLS/SSL LibrariesMongoDB和TLS/SSL库

On Linux platforms, you may observe one of the following statements in the MongoDB log:在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)

These warnings indicate that the system's TLS/SSL libraries are different from the TLS/SSL libraries that the mongod was compiled against. 这些警告表明系统的TLS/SSL库与mongod编译时使用的TLS/SSL库不同。Typically these messages do not require intervention; however, you can use the following operations to determine the symbol versions that mongod expects:通常，这些信息不需要干预；但是，您可以使用以下操作来确定mongod期望的符号版本：

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

These operations will return output that resembles one the of the following lines:这些操作将返回类似于以下行之一的输出：

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

The last two strings in this output are the symbol version and symbol name. Compare these values with the values returned by the following operations to detect symbol version mismatches:

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

This procedure is neither exact nor exhaustive: many symbols used by mongod from the libcrypto library do not begin with CRYPTO_.

AWS EC2

There are two performance configurations to consider:有两种性能配置需要考虑：

• Reproducible performance for performance testing or benchmarking, and性能测试或基准测试的可再现性能，以及
• Raw maximum performance原始最大性能

To tune performance on EC2 for either configuration, you should:要为任一配置调整EC2的性能，您应该：

• Enable AWS Enhanced Networking for your instance. Not all instance types support Enhanced Networking.

  To learn more about Enhanced Networking, see to the AWS documentation.

• Set tcp_keepalive_time to 120.

If you are concerned more about reproducible performance on EC2, you should also:

• Use provisioned IOPS for the storage, with separate devices for journal and data. Do not use the ephemeral (SSD) storage available on most instance types as their performance changes moment to moment. (The i series is a notable exception, but very expensive.)
• Disable DVFS and CPU power saving modes.
  Tip

  See also: 另请参阅：

  Amazon documentation on Processor State Control

• Disable hyperthreading.
  Tip

  See also: 另请参阅：

  Amazon blog post on disabling Hyper-Threading.

• Use numactl to bind memory locality to a single socket.

Azure

Use Premium Storage. Microsoft Azure offers two general types of storage: Standard storage, and Premium storage. MongoDB on Azure has better performance when using Premium storage than it does with Standard storage.

The TCP idle timeout on the Azure load balancer is 240 seconds by default, which can cause it to silently drop connections if the TCP keepalive on your Azure systems is greater than this value. You should set tcp_keepalive_time to 120 to ameliorate this problem.

• To view the keepalive setting on Linux, use one of the following commands:要在Linux上查看保持活动设置，请使用以下命令之一：

  sysctl net.ipv4.tcp_keepalive_time

  Or:或者：

  cat /proc/sys/net/ipv4/tcp_keepalive_time

  The value is measured in seconds.该值以秒为单位进行测量。
  Note

  Although the setting name includes ipv4, the tcp_keepalive_time value applies to both IPv4 and IPv6.尽管设置名称包括ipv4，tcp_keepalive_time值同时适用于ipv4和IPv6。

• To change the tcp_keepalive_time value, you can use one of the following commands, supplying a <value> in seconds:要更改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

  These operations do not persist across system reboots. To persist the setting, add the following line to /etc/sysctl.conf, supplying a <value> in seconds, and reboot the machine:这些操作不会在系统重新启动时持续存在。要保持该设置，请在/etc/sysctl.conf中添加以下行，以秒为单位提供<value>，然后重新启动计算机：

  net.ipv4.tcp_keepalive_time = <value>

  Keepalive values greater than 300 seconds, (5 minutes) will be overridden on mongod and mongos sockets and set to 300 seconds.

• To view the keepalive setting on Windows, issue the following command:要在Windows上查看保持活动设置，请发出以下命令：

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

  The registry value is not present by default. The system default, used if the value is absent, is 7200000 milliseconds or 0x6ddd00 in hexadecimal.
• To change the KeepAliveTime value, use the following command in an Administrator Command Prompt, where <value> is expressed in hexadecimal (e.g. 120000 is 0x1d4c0):

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

  Windows users should consider the Windows Server Technet Article on KeepAliveTime for more information on setting keepalive for MongoDB deployments on Windows systems. Keepalive values greater than or equal to 600000 milliseconds (10 minutes) will be ignored by mongod and mongos.

VMware

MongoDB is compatible with VMware.MongoDB与VMware兼容。

VMware supports memory overcommitment, where you can assign more memory to your virtual machines than the physical machine has available. When memory is overcommitted, the hypervisor reallocates memory between the virtual machines. VMware's balloon driver (vmmemctl) reclaims the pages that are considered least valuable.

The balloon driver resides inside the guest operating system. When the balloon driver expands, it may induce the guest operating system to reclaim memory from guest applications, which can interfere with MongoDB's memory management and affect MongoDB's performance.

Do not disable the balloon driver and memory overcommitment features. This can cause the hypervisor to use its swap which will affect performance. Instead, map and reserve the full amount of memory for the virtual machine running MongoDB. This ensures that the balloon will not be inflated in the local operating system if there is memory pressure in the hypervisor due to an overcommitted configuration.

Ensure that virtual machines stay on a specific ESX/ESXi host by setting VMware's affinity rules. If you must manually migrate a virtual machine to another host and the mongod instance on the virtual machine is the primary, you must first step down the primary and then shut down the instance.

Follow the networking best practices for vMotion and the VMKernel. Failure to follow the best practices can result in performance problems and affect replica set and sharded cluster high availability mechanisms.

It is possible to clone a virtual machine running MongoDB. You might use this function to spin up a new virtual host to add as a member of a replica set. If you clone a VM with journaling enabled, the clone snapshot will be valid. If not using journaling, first stop mongod, then clone the VM, and finally, restart mongod.

KVM

MongoDB is compatible with KVM.

KVM supports memory overcommitment, where you can assign more memory to your virtual machines than the physical machine has available. When memory is overcommitted, the hypervisor reallocates memory between the virtual machines. KVM's balloon driver reclaims the pages that are considered least valuable.

The balloon driver resides inside the guest operating system. When the balloon driver expands, it may induce the guest operating system to reclaim memory from guest applications, which can interfere with MongoDB's memory management and affect MongoDB's performance.

Do not disable the balloon driver and memory overcommitment features. This can cause the hypervisor to use its swap which will affect performance. Instead, map and reserve the full amount of memory for the virtual machine running MongoDB. This ensures that the balloon will not be inflated in the local operating system if there is memory pressure in the hypervisor due to an overcommitted configuration.