Production Notes

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

MMAPv1 Removed

MongoDB 4.2 removes the deprecated MMAPv1 storage engine. To change your MMAPv1 storage engine deployment to WiredTiger Storage Engine, see:


MongoDB Atlas is a cloud-hosted database-as-a-service. MongoDB Cloud Manager, a hosted service, and Ops Manager, an on-premise solution, provide monitoring, backup, and automation of MongoDB instances. For documentation, see Atlas documentation, the MongoDB Cloud Manager documentation and Ops Manager documentation

MongoDB Binaries

Supported Platforms

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


MongoDB 4.0 may lose data during unclean shutdowns on macOS 10.12.x and 10.13.x.

For details, see WT-4018.


Platform Support EOL Notice

Ubuntu 14.04 Support removed in MongoDB 4.2+.
Debian 8 Support removed in MongoDB 4.2+.
Debian 7 Support removed in MongoDB 4.0+, 3.6.6+, 3.4.16+, and 3.2.21+.
SLES 11 Support removed in MongoDB 3.6.4+, 3.4.15+, and 3.2.20+.
Ubuntu 12.04 Support removed in MongoDB 3.6.4+, 3.4.15+, and 3.2.20+.

Upcoming EOL Notice:

Windows 7/2008R2 MongoDB will end support in future releases.
Windows 8/2012 MongoDB will end support in future releases.
Windows 8.1/2012R2 MongoDB will end support in future releases.

Platform 4.2 Community & Enterprise 4.0 Community & Enterprise 3.6 Community & Enterprise 3.4 Community & Enterprise
Amazon Linux 2013.03 and later
Amazon Linux 2    
Debian 8  
Debian 9 3.6.5+  
RHEL/CentOS/Oracle Linux [1] 6.2 and later
RHEL/CentOS/Oracle Linux [1] 7.0 and later
Solaris 11 64-bit       Community only
Ubuntu 14.04  
Ubuntu 16.04
Ubuntu 18.04    
Windows Vista      
Windows 7/Server 2008 R2
Windows 8/2012 R2 and later
macOS 10.12 and later      
macOS 10.11  
[1](1, 2) MongoDB only supports Oracle Linux running the Red Hat Compatible Kernel (RHCK). MongoDB does not support the Unbreakable Enterprise Kernel (UEK).


Platform Support EOL Notice

Ubuntu 16.04 ARM64 Support removed in MongoDB Community 4.2+.

Platform 4.2 Community & Enterprise 4.0 Community & Enterprise 3.6 Community & Enterprise 3.4 Community & Enterprise
Ubuntu 18.04      
Ubuntu 16.04   Enterprise Enterprise

PPC64LE (MongoDB Enterprise Edition)

Platform 4.2 Enterprise 4.0 Enterprise 3.6 Enterprise 3.4 Enterprise
Ubuntu 16.04   Removed starting in 3.6.13 Removed starting in 3.4.21


Platform 4.2 Community & Enterprise 4.0 Community & Enterprise 3.6 Enterprise 3.4 Enterprise
RHEL/CentOS 7 4.0.6+    
RHEL/CentOS 6    
SLES12 4.0.6+    
Ubuntu 18.04 4.0.6+    

Use the Latest Stable Packages

Be sure you have the latest stable release.

All MongoDB releases are available on the MongoDB Download Center page. The MongoDB Download Center page is a good place to verify the current stable release, even if you are installing via a package manager.

For other MongoDB products, refer either to the MongoDB Download Center page or their respective documentation.

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.

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



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.

See also

Allocate Sufficient RAM and CPU provides information about how WiredTiger takes advantage of multiple CPU cores and how to improve operation throughput.

Data Consistency


MongoDB uses write ahead logging to an on-disk journal. Journaling guarantees that MongoDB can quickly recover write operations that were written to the journal but not written to data files in cases where mongod terminated due to a crash or other serious failure.

Leave journaling enabled 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. See Journaling for more information.

Starting in MongoDB 4.0, you cannot specify --nojournal option or storage.journal.enabled: false for replica set members that use the WiredTiger storage engine.

Read Concern

New in version 3.2.

Starting in MongoDB 3.6, you can use causally consistent sessions to read your own writes, if the writes request acknowledgement.

Prior to MongoDB 3.6, you must have issued your write operation with { w: "majority" } write concern and then use either "majority" or "linearizable" read concern for the read operations to ensure that a single thread can read its own writes.

To use read concern level of "majority", replica sets must use WiredTiger storage engine.

You can disable read concern "majority" for a deployment with a three-member primary-secondary-arbiter (PSA) architecture; however, this has implications for change streams (in MongoDB 4.0 and earlier only) and transactions on sharded clusters. For more information, see Disable Read Concern Majority.

Write Concern

Write concern describes the level of acknowledgement requested from MongoDB for write operations. The level of the write concerns affects how quickly the write operation returns. When write operations have a weak write concern, they return quickly. With stronger write concerns, clients must wait after sending a write operation until MongoDB confirms the write operation at the requested write concern level. With insufficient write concerns, write operations may appear to a client to have succeeded, but may not persist in some cases of server failure.

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


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 that is 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.


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 Authentication and Role-Based Access Control.

For additional information and considerations on security, refer to the documents in the Security Section, specifically:

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

Disable HTTP Interface

Changed in version 3.6: MongoDB 3.6 removes the deprecated HTTP interface and REST API to MongoDB.

Earlier versions of MongoDB provide 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.

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.

See also Allocate Sufficient RAM and CPU.

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.

Allocate Sufficient RAM and CPU


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:

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

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.

With WiredTiger, MongoDB utilizes both the WiredTiger internal cache and the filesystem cache.

Starting in MongoDB 3.4, the default WiredTiger internal cache size is the larger of either:

  • 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). 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).


In some instances, such as when running in a container, the database can have memory constraints that are lower than the total system memory. In such instances, this memory limit, rather than the total system memory, is used as the maximum RAM available.

To see the memory limit, see hostInfo.system.memLimitMB.

By default, WiredTiger uses Snappy block compression for all collections and prefix compression for all indexes. 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:

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

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.


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.

To accommodate the additional consumers of RAM, you may have to decrease WiredTiger internal cache size.

The default WiredTiger internal cache size value assumes that there is a single mongod instance per machine. If a single machine contains multiple MongoDB instances, then you should decrease the setting to accommodate the other mongod instances.

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. The exact amount depends on the other processes running in the container. See memLimitMB.

To view statistics on the cache and eviction rate, see the wiredTiger.cache field returned from the serverStatus command.

Compression and Encryption

When using encryption, CPUs equipped with AES-NI instruction-set extensions show significant performance advantages. If you are using MongoDB Enterprise with the Encrypted Storage Engine, choose a CPU that supports AES-NI for better performance.

See also


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.

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.

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. If the NUMA configuration may degrade performance, MongoDB prints a warning.

See also

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.

The following operation demonstrates how to start a MongoDB instance using numactl:

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

The <path> is the path to the program you are starting and the <options> are any optional arguments to pass to the program.

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

Disk and Storage Systems


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.

For the WiredTiger storage engine, given sufficient memory pressure, WiredTiger may store data in swap space.


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.

Remote Filesystems

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). 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: 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. 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.


Using different storage devices 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 or Cloud Hosted Devices

For local block devices attached to a virtual machine instance via the hypervisor or hosted by a cloud hosting provider, the guest operating system should use a noop scheduler for best performance. The noop scheduler allows the operating system to defer I/O scheduling to the underlying hypervisor.

Scheduling for Physical Servers

For physical servers, the operating system should use a deadline scheduler. The deadline scheduler caps maximum latency per request and maintains a good disk throughput that is best for disk-intensive database applications.


Replica Sets

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

Sharded Clusters

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


WiredTiger can compress collection data using one of the following compression library:

  • snappy
    Provides a lower compression rate than zlib or zstd but has a lower CPU cost than either.
  • zlib
    Provides better compression rate than snappy but has a higher CPU cost than both snappy and zstd.
  • zstd (Available starting in MongoDB 4.2)
    Provides better compression rate than both snappy and zlib and has a lower CPU cost than zlib.

By default, WiredTiger uses snappy compression library. To change the compression setting, see storage.wiredTiger.collectionConfig.blockCompressor.

WiredTiger uses prefix compression on all indexes by default.

Clock Synchronization

Use NTP to synchronize the clocks on all components of your MongoDB deployment. Replica sets and sharded clusters running MongoDB 3.4.5 or earlier with the WiredTiger storage engine may experience checkpoint hangs on systems with unreliable clocks.

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, using XFS is strongly recommended for data bearing nodes to avoid performance issues that may occur when using EXT4 with WiredTiger.

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

Set vm.swappiness to 1

“Swappiness” is a Linux kernel setting that influences the behavior of the Virtual Memory manager when it needs to allocate a swap, ranging from 0 to 100, inclusive.

  • A setting of 0 tells the kernel to swap only to avoid out-of-memory problems.
  • A setting of 100 tells it to swap aggressively to disk.

If your host runs kernel versions 3.5 or later, or RHEL / CentOS kernel 2.6.32-303 or later, setting this value to 0 could disable swapping. Set this to 1.

To see what the current swappiness level is, run:

example@example:$ cat /proc/sys/vm/swappiness


To change swappiness while the system is running, run:

example@example:$ sysctl vm.swappiness=1

To change swappiness permanently, edit the /etc/sysctl.conf file in your preferred text editor and change this value:

vm.swappiness = 1

MongoDB and TLS/SSL Libraries

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

<path to TLS/SSL libs>/<version>: no version information available (required by /usr/bin/mongod)
<path to TLS/SSL libs>/<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 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>/*
objdump -T <path to TLS/SSL libs>/*

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

MongoDB on Windows

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

MongoDB on Virtual Environments

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

For all platforms, consider Scheduling.


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:

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.

  • Disable hyperthreading.

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


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.


You will need to restart mongod and mongos processes for new system-wide keepalive settings to take effect.

On Linux systems:

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

    sysctl net.ipv4.tcp_keepalive_time


    cat /proc/sys/net/ipv4/tcp_keepalive_time

    The value is measured in seconds.


    Although the path includes ipv4, the tcp_keepalive_time value applies to both IPv4 and IPv6.

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

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


    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\ /t REG_DWORD /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.


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.

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.


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.

Performance Monitoring


Starting in version 4.0, MongoDB offers free Cloud monitoring for standalones and replica sets. For more information, see Free Monitoring.


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


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