Navigation
This version of the documentation is archived and no longer supported.

Production Notes

On this page

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

Note

MongoDB Cloud Manager is a hosted service that provides monitoring, backup, and automated deployment of MongoDB instances. See MongoDB Cloud Manager and the MongoDB Cloud Manager documentation for more information.

Packages

MongoDB

Be sure you have the latest stable release. All releases are available on the Downloads page. This is a good place to verify what is current, even if you then choose to install via a package manager.

Always use 64-bit builds for production. The 32-bit build MongoDB offers for test and development environments is not suitable for production deployments as it can store no more than 2GB of data. See the 32-bit limitations page for more information.

32-bit builds exist to support use on development machines.

Operating Systems

MongoDB distributions are currently available for Mac OS X, Linux, Windows Server 2008 R2 64bit, Windows 7 (32 bit and 64 bit), Windows Vista, and Solaris platforms.

Note

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.

Concurrency

In earlier versions of MongoDB, all write operations contended for a single readers-writer lock on the MongoDB instance. As of version 2.2, each database has a readers-writer lock that allows concurrent reads access to a database, but gives exclusive access to a single write operation per database. See the Concurrency page for more information.

Journaling

MongoDB uses write ahead logging to an on-disk journal to guarantee that MongoDB is able to quickly recover the write operations following a crash or other serious failure.

In order to ensure that mongod will be able to recover its data files and keep the data files in a valid state following a crash, leave journaling enabled. See Journaling for more information.

Networking

Use Trusted Networking Environments

Always run MongoDB in a trusted environment, with network rules that prevent access from all unknown machines, systems, and networks. As with any sensitive system dependent on network access, your MongoDB deployment should only be accessible to specific systems that require access, such as application servers, monitoring services, and other MongoDB components.

Note

By default, authorization is not enabled and mongod assumes a trusted environment. You can enable security/auth mode if you need it.

See documents in the Security Section for additional information, specifically:

For Windows users, consider the Windows Server Technet Article on TCP Configuration when deploying MongoDB on Windows.

Connection Pools

To avoid overloading the connection resources of a single mongod or mongos instance, ensure that clients maintain reasonable connection pool sizes.

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

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.

Hardware Requirements and Limitations

The hardware for the most effective MongoDB deployments have the following properties:

Allocate Sufficient RAM and CPU

As with all software, more RAM and a faster CPU clock speed are important for performance.

In general, databases are not CPU bound. As such, increasing the number of cores can help, but does not provide significant marginal return.

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

Commodity (SATA) spinning drives are often a good option, as the random I/O performance increase with more expensive spinning drives is not that dramatic (only on the order of 2x). Using SSDs or increasing RAM may be more effective in increasing I/O throughput.

Avoid Remote File Systems

  • Remote file storage can create performance problems in MongoDB. See Remote Filesystems for more information about storage and MongoDB.

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.

When running MongoDB servers and clients on NUMA hardware, you should configure a memory interleave policy so that the host behaves in a non-NUMA fashion. MongoDB checks NUMA settings on start up when deployed on Linux (since version 2.0) and Windows (since version 2.6) machines, and prints a warning if the NUMA configuration may degrade performance.

See also

Configuring NUMA on Windows

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

Configuring NUMA on Linux

When running MongoDB on Linux, you may instead use the numactl command and start the MongoDB programs (mongod, including the config servers; mongos; or clients) in the following manner:

copy 
numactl --interleave=all <path>

where <path> is the path to the program you are starting. Then, disable zone reclaim in the proc settings using the following command:

copy 
echo 0 > /proc/sys/vm/zone_reclaim_mode

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

Assign swap space for your systems. Allocating swap space can avoid issues with memory contention and can prevent the OOM Killer on Linux systems from killing mongod.

The method mongod uses to map memory files to memory ensures that the operating system will never store MongoDB data in swap space. On Windows systems, MongoDB requires extra swap space due to commitment limits. For details, see MongoDB on Windows.

RAID

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

RAID-5 and RAID-6 do not typically provide sufficient performance to support a MongoDB deployment.

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

The Network File System protocol (NFS) is not recommended for use with MongoDB as some versions perform poorly.

Performance problems arise when both the data files and the journal files are hosted on NFS. You may experience better performance if you place the journal on local or iscsi volumes. If you must use NFS, add the following NFS options to your /etc/fstab file: bg, nolock, and noatime.

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.

Note

This will affect your ability to create snapshot-style backups of your data, since the files will be on different devices and volumes.

Scheduling for Virtual Devices

Local block devices attached to virtual machine instances via the hypervisor should use a noop scheduler for best performance. The noop scheduler allows the operating system to defer I/O scheduling to the underlying hypervisor.

Architecture

Write Concern

Write concern describes the guarantee that MongoDB provides when reporting on the success of a write operation. The strength of the write concerns determine the level of guarantee. When inserts, updates and deletes have a weak write concern, write operations return quickly. In some failure cases, write operations issued with weak write concerns may not persist. With stronger write concerns, clients wait after sending a write operation for MongoDB to confirm the write operations.

MongoDB provides different levels of write concern to better address the specific needs of applications. Clients may adjust write concern to ensure that the most important operations persist successfully to an entire MongoDB deployment. For other less critical operations, clients can adjust the write concern to ensure faster performance rather than ensure persistence to the entire deployment.

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

Replica Sets

See the Replica Set Architectures document for an overview of architectural considerations for replica set deployments.

Sharded Clusters

See the Sharded Cluster Production Architecture document for an overview of recommended sharded cluster architectures for production deployments.

Platforms

MongoDB on Linux

Important

The following discussion only applies to Linux, and therefore does not affect deployments where mongod instances run other UNIX-like systems or on Windows.

Kernel and File Systems

When running MongoDB in production on Linux, it is recommended that you use Linux kernel version 2.6.36 or later.

MongoDB preallocates its database files before using them and often creates large files. As such, you should use the Ext4 and XFS file systems:

  • In general, if you use the Ext4 file system, use at least version 2.6.23 of the Linux Kernel.

  • In general, if you use the XFS file system, use at least version 2.6.25 of the Linux Kernel.

  • Some Linux distributions require different versions of the kernel to support using ext4 and/or xfs:

    Linux Distribution Filesystem Kernel Version
    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

Important

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

MongoDB Enterprise and TLS/SSL Libraries

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

copy 
<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. Typically these messages do not require intervention; however, you can use the following operations to determine the symbol versions that mongod expects:

copy 
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:

copy 
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:

copy 
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

Install Hotfix

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.

Install this hotfix to obtain significant performance improvements on MongoDB 2.6.6 and later releases in the 2.6 series.

Configure Windows Page File

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.

Note

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

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

For all platforms, consider Scheduling for Virtual Devices.

EC2

When available, enable AWS’s Enhanced Networking for your instance. Not all instance types support Enhanced Networking. Refer to the AWS documentation for more information.

VMWare

MongoDB is compatible with VMWare. As some users have run into issues with VMWare’s memory overcommit feature, disabling the feature is recommended.

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.

OpenVZ

Some users have had issues when running MongoDB on some older version of OpenVZ due to its handling of virtual memory, as with VMWare.

This issue seems to have been resolved in the more recent versions of OpenVZ.

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:

copy 
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-present. MongoDB, Mongo, and the leaf logo are registered trademarks of MongoDB, Inc.