This page details system configurations that affect MongoDB, especially in production.
MongoDB Management Service (MMS) is a hosted monitoring service which collects and aggregates diagnostic data to provide insight into the performance and operation of MongoDB deployments. See the MMS Website and the MMS documentation for more information.
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 for more information.
32-bit builds exist to support use on development machines.
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.
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.
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.
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 Write Concern for more information about choosing an appropriate write concern level for your deployment.
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.
The hardware for the most effective MongoDB deployments have the following properties:
The discussion of NUMA in this section only applies to Linux, and therefore does not affect deployments where mongod instances run other UNIX-like systems or on Windows.
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 or high system process usage.
When running MongoDB on NUMA hardware, you should disable NUMA for MongoDB and instead set an interleave memory policy.
MongoDB version 2.0 and greater checks these settings on start up when deployed on a Linux-based system, and prints a warning if the system is NUMA-based.
To disable NUMA for MongoDB and set an interleave memory policy, use the numactl command and start mongod in the following manner:
numactl --interleave=all /usr/bin/local/mongod
Then, disable zone reclaim in the proc settings using the following command:
echo 0 > /proc/sys/vm/zone_reclaim_mode
To fully disable NUMA, you must perform both operations. For more information, see the Documentation for /proc/sys/vm/*.
See the The MySQL “swap insanity” problem and the effects of NUMA post, which describes the effects of NUMA on databases. This blog post addresses the impact of NUMA for MySQL, but the issues for MongoDB are similar. The post introduces NUMA and its goals, and illustrates how these goals are not compatible with production databases.
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.
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.
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.
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.
This will affect your ability to create snapshot-style backups of your data, since the files will be on different devices and volumes.
The following discussion only applies to Linux, and therefore does not affect deployments where mongod instances run other UNIX-like systems or on Windows.
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|
|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|
MongoDB requires a filesystem that supports fsync() on directories. For example, HGFS and Virtual Box’s shared folders do not support this operation.
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.
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.
The section describes considerations when running MongoDB in some of the more common virtual environments.
MongoDB is compatible with EC2 and requires no configuration changes specific to the environment.
You may alternately choose to obtain a set of Amazon Machine Images (AMI) that bundle together MongoDB and Amazon’s Provisioned IOPS storage volumes. Provisioned IOPS can greatly increase MongoDB’s performance and ease of use. For more information, see this blog post.
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 consistent. If not using journaling, first stop mongod, then clone the VM, and finally, restart mongod.
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.
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: