翻译或纠错本页面

生产环境指南

On this page

This page details system configurations that affect MongoDB, especially when running in production.

注解

MongoDB Cloud Manager，主机服务， Ops Manager 一项托管监控服务，该服务提供MongoDB的监控、备份和自动化。请参见|mms-docs| 和 Ops Manager documentation 查阅更多信息。

MongoDB Binaries

支持平台

For running in production, refer to the Recommended Platforms for operating system recommendations.

在 3.2 版更改: MongoDB can now use the WiredTiger storage engine on all supported platforms.

x86_64

Platform 3.4 Community & Enterprise 3.2 Community & Enterprise 3.0 Community & Enterprise

从MongoDB3.2 开始， MMAPv1 提供 集合级别的锁定 。所有集合有一个单独的读写锁，允许多个客户端同时修改不同集合中的文档。

对于MongoDB2.2到2.6的系列版本，每个数据库都有一个读写锁，允许对同一个数据库的并发读，但是每个数据库的一个单一写操作只能互斥获取。 查阅 Concurrency 页面了解更多信息。在MongoDB的早期版本中，所有竞争单一读写锁的写操作都针对整个 mongod 实例。

 ✓ ✓ ✓ ✓

WiredTiger 支持对一个集合中文档的读写并发访问。在进行写操作的时候，客户端可以读取文档，并且多线程也可以同时修改一个集合中的不同文档。

 ✓ ✓    
Debian 7 ✓ ✓ ✓ ✓
Fedora 8+     ✓ ✓

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

 ✓ ✓ ✓ ✓
RHEL/CentOS 7.0+ ✓ ✓ ✓  
SLES 11 ✓ ✓ ✓ ✓
SLES 12 ✓      

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

 ✓ ✓ ✓ ✓

默认情况下， authorization 没有开启， mongod 假定这是一个可信赖的环境。当你需要时，你可以开启 authorization 模式。了解MongoDB中支持的授权机制及认证，查阅 认证 and Role-Based Access Control 。

 ✓ ✓ ✓ ✓

请查阅 Security Section 了解更多关于安全方面的信息及考量，具体来说：

 ✓ ✓ ✓  
Ubuntu 16.04 ✓ ✓    

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

 ✓ ✓ ✓ ✓
Windows Vista/Server 2008R2/2012+ ✓ ✓ ✓ ✓
OS X 10.7+ ✓ ✓    

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

Platform 3.4 Community & Enterprise
Ubuntu 16.04 ✓

PPC64LE (MongoDB Enterprise Edition)

Platform 3.4 Enterprise

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

 ✓
Ubuntu 16.04 ✓

s390x (MongoDB Enterprise Edition)

Platform 3.4 Enterprise
RHEL/CentOS 7.2 ✓
SLES 11 ✓
SLES 12 ✓
Ubuntu 16.04 ✓

Use the Latest Stable Packages

当在NUMA硬件上运行MongoDB时，你应当为MongoDB禁用NUMA并设置交错的内存策略作为替代。当部署在Linux（2.0版本之后）和Windows（2.6版本之后），MongoDB在启动的时候会检测NUMA配置。如果NUMA配置降低了性能，MongoDB会打印警告。

` The MySQL “swap insanity” problem and the effects of NUMA <http://jcole.us/blog/archives/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/>`_ 博客，描述了NUMA对数据库的影响。这篇博客介绍了NUMA和它的目标，并且展示了这些目标为何不能与生产环境下的数据库兼容。尽管这篇博客解决了NUMA对MySQL的影响，但是对MongoDB来说问题是相同的。

MongoDB dbPath

The files in the dbPath directory must correspond to the configured storage engine. mongod will not start if dbPath contains data files created by a storage engine other than the one specified by --storageEngine.

在 3.2 版更改: As of MongoDB 3.2, MongoDB uses the WiredTiger storage engine by default.

在 3.0 版更改: 为了完全禁止 NUMA的行为，您必须同时执行操作。查阅 Documentation for /proc/sys/vm/* 了解更多信息。

mongod must possess read and write permissions for the specified dbPath.

Concurrency

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

在 3.0 版更改: Beginning with MongoDB 3.0, MMAPv1 provides collection-level locking: All collections have a unique readers-writer lock that allows multiple clients to modify documents in different collections at the same time.

For MongoDB versions 2.2 through 2.6 series, each database has a readers-writer lock that allows concurrent read access to a database, but gives exclusive access to a single write operation per database. See the Concurrency page for more information. In earlier versions of MongoDB, all write operations contended for a single readers-writer lock for the entire mongod instance.

WiredTiger

WiredTiger supports concurrent access by readers and writers to the documents in a collection. Clients can read documents while write operations are in progress, and multiple threads can modify different documents in a collection at the same time.

参见

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

Data Consistency

Journaling

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

如果您决定使用NFS，将下列NFS选项添加到您的 /etc/fstab 文件： bg, nolock ，以及 noatime 。

Read Concern

3.2 新版功能.

If using "majority" or "linearizable" read concern for read operations, use { w: "majority" } write concern for write operations on the primary to ensure that a single thread can read its own writes.

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

  • 对于WiredTiger存储殷勤，您也可以在一个不同的存储设备上存储殷勤。请查阅 storage.wiredTiger.engineConfig.directoryForIndexes 。

  • 使用不同的存储设备将会影响您创建备份数据快照风格的能力，因为文件将会存储在不同的设备和有不同的容量。

Write Concern

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

See the Write Concern document for more information about choosing an appropriate write concern level for your deployment.

Networking

Use Trusted Networking Environments

查阅 Replica Set Architectures 文档了解复制集部署的架构考量概述。

重要

By default, authorization is not enabled, and mongod assumes a trusted environment. Enable authorization mode as needed. For more information on authentication mechanisms supported in MongoDB as well as authorization in MongoDB, see 认证 and Role-Based Access Control.

查阅 Sharded Cluster Production Architecture 文档了解生产部署推荐的分片集群架构的概览。

默认地，WiredTiger 使用 snappy 压缩库。查阅 storage.wiredTiger.collectionConfig.blockCompressor 修改压缩配置。

Disable HTTP Interface

MongoDB provides an HTTP interface to check the status of the server and, optionally, run queries. The HTTP interface is disabled by default. Do not enable the HTTP interface in production environments.

3.2 版后已移除: 如果系统中安装了的话，MongoDB使用 GNU C Library (glibc) 。MongoDB要求版本最低为 glibc-2.12-1.2.el6 ，以避免一个早期版本的已知bug。为了最佳结果，请至少使用版本2.13。

See HTTP Status Interface.

Manage Connection Pool Sizes

Avoid overloading the connection resources of a mongod or mongos instance by adjusting the connection pool size to suit your use case. Start at 110-115% of the typical number of current database requests, and modify the connection pool size as needed. Refer to the Connection Pool Options for adjusting the connection pool size.

The connPoolStats command returns information regarding the number of open connections to the current database for mongos and mongod instances in sharded clusters.

MongoDB需要 目录 支持 fsync() 的文件系统。例如，HGFS和Virtual Box的共享文件夹 不支持 该操作。

Hardware Considerations

MongoDB is designed specifically with commodity hardware in mind and has few hardware requirements or limitations. MongoDB’s core components run on little-endian hardware, primarily x86/x86_64 processors. Client libraries (i.e. drivers) can run on big or little endian systems.

禁用BIOS中的NUMA。如果不能禁用，请参见 MongoDB on NUMA Hardware。

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

对于标准的块设备，您可以运行 sudo blockdev --report 获取预加载设置， sudo blockdev --setra <value> <device> 更改预加载的值。更多信息请参见您特定操作系统的系统手册。

使用网络时间协议 (NTP) 来同步您各个主机的时间。这是在分片集群中尤其重要。

Increasing the amount of RAM accessible to MongoDB may help reduce the frequency of page faults.

WiredTiger

The WiredTiger storage engine is multithreaded and can take advantage of additional CPU cores. Specifically, the total number of active threads (i.e. concurrent operations) relative to the number of available CPUs can impact performance:

  • 这些警告报名系统的TLS/SSL函数库与 编译 mongod 的TLS/SSL函数库不同。一般说来，这些信息并不需要在意；但是，您可以使用下列操作了解 mongod 希望的符号版本。

  • Throughput decreases as the number of concurrent active operations exceeds the number of CPUs by some threshold amount.

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

下面步骤既不精确也不详尽：许多 mongod 从 libcrypto` 函数库中使用的符号并不以  ``CRYPTO_ 开头。

Starting in 3.4, the WiredTiger internal cache, by default, will use the larger of either:

  • 50% of RAM minus 1 GB, or
  • 256 MB.

微软已经发布了一个Windows 7和Windows Server 2008 R2的热修复插件， KB2731284 ，修复了这些操作系统中内存映射文件使用中的一个bug，这个bug可能会影响使用MMAPv1存储引擎的MongoDB性能。

安装这个热修复插件以获取2.6系列中MongoDB 2.6.6及之后版本的重大性能提高（限于使用MMAPv1 ），以及当使用MMAPv1 作为存储引擎时，3.0和之后的版本。

注解

The storage.wiredTiger.engineConfig.cacheSizeGB limits the size of the WiredTiger internal cache. The operating system will use the available free memory for filesystem cache, which allows the compressed MongoDB data files to stay in memory. In addition, the operating system will use any free RAM to buffer file system blocks and file system cache.

配置页面文件以保证最小的和最大的页面文件大小等于或者至少是32GB。如果在使用高峰时，您希望对多个数据库或集合进行并发写入，使用这个大小的整数倍。然而，页面文件大小不要超过数据库的最大大小。

由于在高峰使用期间，不管写入是否真实存在，Windows都需要足够的空间来满足各区可写的内存映射文件，因为需要庞大的页面文件。

页面文件并不会被数据库存储上使用，因此在正常的MongoDB操作期间将不会接受写入。因此，页面文件不会影响性能，但是它必须存在，并且足够大以保证数据库使用高峰时期能够满足windows的提交原则。

动态的页面文件大小太小了，以至于不能满足一个活跃MongoDB部署快速变化的提交开销。这将会造成短暂的超量使用情形，可能会导致一个 VirtualProtec 错误 1455而导致突然的服务器宕机。

Compression and Encryption

对于使用WiredTiger存储引擎的MongoDB实例，Windows上的性能与Linux上运行的性能不相上下。

参见

Concurrency

Use Solid State Disks (SSDs)

MongoDB has good results and a good price-performance ratio with SATA SSD (Solid State Disk).

Use SSD if available and economical. Spinning disks can be performant, but SSDs’ capacity for random I/O operations works well with the update model of MMAPv1.

MongoDB与 EC2兼容。 MongoDB Cloud Manager 提供了与Amazon Web Services (AWS) 的集成，您可以直接从 MongoDB Cloud Manager 部署新的EC2实例。查阅 Configure AWS Integration 了解更多细节。

MongoDB and NUMA Hardware

Running MongoDB on a system with Non-Uniform Access Memory (NUMA) can cause a number of operational problems, including slow performance for periods of time and high system process usage.

在 storage.journal.enabled 设置为 true 的情况下，这些关闭并不会造成数据丢失。您可以在之后的任意时间安全地重启 mongod 。

参见

  • The MySQL “swap insanity” problem and the effects of NUMA post, which describes the effects of NUMA on databases. The post introduces NUMA and its goals, and illustrates how these goals are not compatible with production databases. Although the blog post addresses the impact of NUMA for MySQL, the issues for MongoDB are similar.

  • Azure 负载均衡器上的TCP keepalive默认设置为240秒，在Azure系统上的TCP keepalive的值超过这个值时，它将会自动关闭连接。 您可以将 tcp_keepalive_time 设置为120来缓解这个问题。

Configuring NUMA on Windows

On Windows, memory interleaving must be enabled through the machine’s BIOS. Consult your system documentation for details.

Configuring NUMA on Linux

When running MongoDB on Linux, you should disable zone reclaim in the sysctl settings using one of the following commands:

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

sudo sysctl -w vm.zone_reclaim_mode=0

Then, you should use numactl to start your mongod instances, including the config servers, mongos instances, and any clients. If you do not have the numactl command, refer to the documentation for your operating system to install the numactl package.

这些操作在系统重启之后并不会持久保持。将下面的行添加到 /etc/sysctl.conf 以保存这个配置：

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

在Linux系统上，通过复写keepalive的值大于5分钟， mongod 和 mongos 在它们自己的socket上将keepalive限制最大为300秒（5分钟）。

To fully disable NUMA behavior, you must perform both operations. For more information, see the Documentation for /proc/sys/vm/*.

Disk and Storage Systems

Swap

默认不展示注册值。如果缺少该数值，系统默认为7200000 毫秒 或者十六进制的 0x6ddd00 。

以管理员的身份运行下列命令 Command Prompt 来修改 KeepAliveTime 值。其中， <value> 是以十六进制的形式进行表示的（例如， 0x0124c0 为 120000）：

Windows用户应该参考 Windows Server Technet 上关于KeepAliveTime的文章 了解关于在Windows系统上为MongoDB部署设置 keep alive的更多信息。

RAID

Most MongoDB deployments should use disks backed by RAID-10.

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

Avoid RAID-0 with MongoDB deployments. While RAID-0 provides good write performance, it also provides limited availability and can lead to reduced performance on read operations, particularly when using Amazon’s EBS volumes.

Remote Filesystems

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

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

If you decide to use NFS, add the following NFS options to your /etc/fstab file: bg, nolock, and noatime.

%util： 这对快速查看来说是最有用的字段，它指明了设备/驱动器使用时间的百分比。

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. See storage.wiredTiger.engineConfig.directoryForIndexes.

注解

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

Scheduling

Scheduling for Virtual or Cloud Hosted Devices

为了对您的MongoDB数据库进行备份，请查阅 MongoDB Backup Methods Overview 。

Scheduling for Physical Servers

` 博客：10分钟完成MongoDB的容量规划及硬件配置 <https://www.mongodb.com/blog/post/capacity-planning-and-hardware-provisioning-mongodb-ten-minutes?jmp=docs>`_

Compression

WiredTiger can compress collection data using either snappy or zlib compression library. snappy provides a lower compression rate but has little performance cost, whereas zlib provides better compression rate but has a higher performance cost.

MongoDB为下列支持平台提供了搭建版本。在生产环境中 运行，请查阅 Recommended Platforms 了解操作系统的建议。

WiredTiger uses prefix compression on all indexes by default.

Platform Specific Considerations

注解

MongoDB uses the GNU C Library (glibc) if available on a system. MongoDB requires version at least glibc-2.12-1.2.el6 to avoid a known bug with earlier versions. For best results use at least version 2.13.

MongoDB on Linux

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. If possible, use XFS as it generally performs better with MongoDB.

With the WiredTiger storage engine, use of XFS is strongly recommended to avoid performance issues that may occur when using EXT4 with WiredTiger.

With the MMAPv1 storage engine, MongoDB preallocates its database files before using them and often creates large files. As such, you should use the XFS or EXT4 file systems. If possible, use XFS as it generally performs better with MongoDB.

  • In general, if you use the XFS file system, use at least version 2.6.25 of the Linux Kernel.
  • If you use the EXT4 file system, use at least version 2.6.28 of the Linux Kernel.
  • On Red Hat Enterprise Linux and CentOS, use at least version 2.6.18-194 of the Linux kernel.

fsync() on Directories

重要

MongoDB requires a filesystem that supports fsync() on directories. For example, HGFS and Virtual Box’s shared folders do not support this operation.

所有MongoDB版本都可以在 ` 下载 <http://www.mongodb.org/downloads>`_ 页面进行下载。 ` 下载 <http://www.mongodb.org/downloads>`_ 页面是一个非常好的地方用来验证当前的文档版本，即使您是通过包管理器进行安装的。

On Linux platforms, you may observe one of the following statements in the MongoDB log:

<path to SSL libs>/libssl.so.<version>: no version information available (required by /usr/bin/mongod)
<path to 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. Typically these messages do not require intervention; however, you can use the following operations to determine the symbol versions that mongod expects:

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_.

MongoDB on Windows

MongoDB 3.0 Using WiredTiger

For MongoDB instances using the WiredTiger storage engine, performance on Windows is comparable to performance on Linux.

MongoDB Using MMAPv1

Install Hotfix for MongoDB 2.6.6 and Later

Microsoft has released a hotfix for Windows 7 and Windows Server 2008 R2, KB2731284, that repairs a bug in these operating systems’ use of memory-mapped files that adversely affects the performance of MongoDB using the MMAPv1 storage engine.

Install this hotfix to obtain significant performance improvements on MongoDB 2.6.6 and later releases in the 2.6 series, which use MMAPv1 exclusively, and on 3.0 and later when using MMAPv1 as the storage engine.

Configure Windows Page File For MMAPv1

Configure the page file such that the minimum and maximum page file size are equal and at least 32 GB. Use a multiple of this size if, during peak usage, you expect concurrent writes to many databases or collections. However, the page file size does not need to exceed the maximum size of the database.

A large page file is needed as Windows requires enough space to accommodate all regions of memory mapped files made writable during peak usage, regardless of whether writes actually occur.

The page file is not used for database storage and will not receive writes during normal MongoDB operation. As such, the page file will not affect performance, but it must exist and be large enough to accommodate Windows’ commitment rules during peak database use.

注解

Dynamic page file sizing is too slow to accommodate the rapidly fluctuating commit charge of an active MongoDB deployment. This can result in transient overcommitment situations that may lead to abrupt server shutdown with a VirtualProtect error 1455.

MongoDB on Virtual Environments

This section describes considerations when running MongoDB in some of the more common virtual environments.

For all platforms, consider Scheduling.

EC2

MongoDB is compatible with EC2. MongoDB Cloud Manager provides integration with Amazon Web Services (AWS) and lets you deploy new EC2 instances directly from MongoDB Cloud Manager. See Configure AWS Integration for more details.

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.

For all MMAPv1 MongoDB deployments using Azure, you must mount the volume that hosts the mongod instance’s dbPath with the Host Cache Preference READ/WRITE. This applies to all Azure deployments running MMAPv1, using any guest operating system.

If your volumes have inappropriate cache settings, MongoDB may eventually shut down with the following error:

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

These shut downs do not produce data loss when storage.journal.enabled is set to true. You can safely restart mongod at any time following this event.

The performance characteristics of MongoDB may change with READ/WRITE caching enabled.

The TCP keepalive 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.

On Linux systems:

  • To view the keep alive setting, you can use one of the following commands:

    sysctl net.ipv4.tcp_keepalive_time

    Or:

    cat /proc/sys/net/ipv4/tcp_keepalive_time

    The value is measured in seconds.

  • To change the tcp_keepalive_time value, you can use one of the following command:

    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:

    net.ipv4.tcp_keepalive_time = <value>

    On Linux, mongod and mongos processes limit the keepalive to a maximum of 300 seconds (5 minutes) on their own sockets by overriding keepalive values greater than 5 minutes.

For Windows systems:

  • To view the keep alive setting, issue the following command:

    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\ /v KeepAliveTime /d <value>

    Windows users should consider the Windows Server Technet Article on KeepAliveTime for more information on setting keep alive for MongoDB deployments on Windows systems.

VMWare

MongoDB is compatible with 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.

You can disable the balloon driver and VMWare’s memory overcommitment feature to mitigate these problems. However, disabling the balloon driver can cause the hypervisor to use its swap, as there is no other available mechanism to perform the memory reclamation. Accessing data in swap is much slower than accessing data in memory, which can in turn affect performance. Instead of disabling the balloon driver and memory overcommitment features, 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.

When using MongoDB with VMWare, ensure that the CPU reservation does not exceed more than 2 virtual CPUs per physical core.

Disable VMWare’s Migration with vMotion (“live migration”). The live migration of a virtual machine can cause 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.

You can disable the balloon driver and KVM’s memory overcommitment feature to mitigate these problems. However, disabling the balloon driver can cause the hypervisor to use its swap, as there is no other available mechanism to perform the memory reclamation. Accessing data in swap is much slower than accessing data in memory, which can in turn affect performance. Instead of disabling the balloon driver and memory overcommitment features, 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.

When using MongoDB with KVM, ensure that the CPU reservation does not exceed more than 2 virtual CPUs per physical core.

Performance Monitoring

iostat

On Linux, use the iostat command to check if disk I/O is a bottleneck for your database. Specify a number of seconds when running iostat to avoid displaying stats covering the time since server boot.

For example, the following command will display extended statistics and the time for each displayed report, with traffic in MB/s, at one second intervals:

iostat -xmt 1

Key fields from iostat:

  • %util: this is the most useful field for a quick check, it indicates what percent of the time the device/drive is in use.
  • avgrq-sz: average request size. Smaller number for this value reflect more random IO operations.

bwm-ng

bwm-ng is a command-line tool for monitoring network use. If you suspect a network-based bottleneck, you may use bwm-ng to begin your diagnostic process.

Backups

To make backups of your MongoDB database, please refer to MongoDB Backup Methods Overview.

© MongoDB, Inc 2008-2017. MongoDB, Mongo, and the leaf logo are registered trademarks of MongoDB, Inc.

Report a Problem