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 changeyour MMAPv1 storage engine deployment to WiredTiger Storage Engine, see:

• Change Standalone to WiredTiger
• Change Replica Set to WiredTiger
• Change Sharded Cluster to WiredTiger

Note

MongoDB Atlas is acloud-hosted database-as-a-service. MongoDB Cloud Manager, a hosted service,and Ops Manager,an on-premise solution, provide monitoring, backup, andautomation of MongoDB instances. For documentation, see Atlasdocumentation, theMongoDB Cloud Manager documentation and Ops Manager documentation

MongoDB Binaries

Supported Platforms

For running in production, refer to theRecommended Platforms for operating systemrecommendations.

Note

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

For details, see WT-4018.

x86_64

ARM64

PPC64LE (MongoDB Enterprise Edition)

s390x

Recommended Platforms

While MongoDB supports a variety of platforms, the following operatingsystems are recommended for production use:

• Amazon Linux 2
• Debian 9 and 10
• RHEL / CentOS 6, 7, and 8
• SLES 12
• Ubuntu LTS 16.04 and 18.04
• Windows Server 2016

See also

Platform Specific Considerations

Use the Latest Stable Packages

Be sure you have the latest stable release.

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

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

MongoDB dbPath

The files in the dbPath directory must correspondto the configured storage engine. mongod will not start ifdbPath contains data files created by a storageengine other than the one specified by —storageEngine.

mongod must possess read and write permissions for the specifieddbPath.

Concurrency

WiredTiger

WiredTiger supports concurrent access byreaders and writers to the documents in a collection. Clients can readdocuments while write operations are in progress, and multiple threadscan modify different documents in a collection at the same time.

See also

Allocate Sufficient RAM and CPU provides information about how WiredTigertakes advantage of multiple CPU cores and how to improve operationthroughput.

Data Consistency

Journaling

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

Leave journaling enabled in order to ensure that mongod willbe able to recover its data files and keep the data files in a validstate following a crash. See Journaling formore information.

Starting in MongoDB 4.0, you cannot specify —nojournal option or storage.journal.enabled:false for replica set members that use theWiredTiger 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 requestacknowledgement.

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

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

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

Write Concern

Write concern describes the level ofacknowledgement requested from MongoDB for write operations. The levelof 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 writeoperation until MongoDB confirms the write operation at the requestedwrite concern level. With insufficient write concerns, write operationsmay appear to a client to have succeeded, but may not persist in somecases of server failure.

See the Write Concern document for moreinformation about choosing an appropriate write concern level for yourdeployment.

Networking

Use Trusted Networking Environments

Always run MongoDB in a trusted environment, with network rules thatprevent access from all unknown machines, systems, and networks. Aswith any sensitive system that is dependent on network access, yourMongoDB deployment should only be accessible to specific systems thatrequire access, such as application servers, monitoring services, andother MongoDB components.

Important

By default, authorization is notenabled, and mongod assumes a trusted environment. Enableauthorization mode as needed. For moreinformation on authentication mechanisms supported in MongoDB aswell as authorization in MongoDB, see Authenticationand Role-Based Access Control.

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

• Security Checklist
• Network and Configuration Hardening

For Windows users, consider the Windows Server Technet Article on TCPConfigurationwhen deploying MongoDB on Windows.

Disable HTTP Interface

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

Earlier versions of MongoDB provide an HTTP interface to check the status of the serverand, optionally, run queries. The HTTP interface is disabled by default. Donot enable the HTTP interface in production environments.

Manage Connection Pool Sizes

Avoid overloading the connection resources of a mongod ormongos instance by adjusting the connection pool size to suityour use case. Start at 110-115% of the typical number of current databaserequests, and modify the connection pool size as needed. Refer to theConnection Pool Options for adjusting the connection pool size.

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

See also Allocate Sufficient RAM and CPU.

Hardware Considerations

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

Allocate Sufficient RAM and CPU

WiredTiger

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

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

The threshold depends on your application. You can determine theoptimum number of concurrent active operations for your application byexperimenting and measuring throughput. The output frommongostat provides statistics on the number of activereads/writes in the (ar|aw) column.

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

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

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

For example, on a system with a total of 4GB of RAM the WiredTigercache 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 256MB to the WiredTiger cache because that is more than half of thetotal RAM minus one gigabyte (0.5 (1.25 GB - 1 GB) = 128 MB < 256 MB).

Note

In some instances, such as when running in a container, the databasecan have memory constraints that are lower than the total systemmemory. In such instances, this memory limit, rather than the totalsystem 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 collectionsand prefix compression for all indexes. Compression defaults are configurableat a global level and can also be set on a per-collection and per-indexbasis during collection and index creation.

Different representations are used for data in the WiredTiger internal cacheversus the on-disk format:

• Data in the filesystem cache is the same as the on-disk format, includingbenefits of any compression for data files. The filesystem cache is usedby the operating system to reduce disk I/O.
• Indexes loaded in the WiredTiger internal cache have a different datarepresentation to the on-disk format, but can still take advantage ofindex prefix compression to reduce RAM usage. Index prefix compressiondeduplicates common prefixes from indexed fields.
• Collection data in the WiredTiger internal cache is uncompressedand uses a different representation from the on-disk format. Blockcompression can provide significant on-disk storage savings, butdata must be uncompressed to be manipulated by the server.

Via the filesystem cache, MongoDB automatically uses all free memorythat is not used by the WiredTiger cache or by other processes.

To adjust the size of the WiredTiger internal cache, seestorage.wiredTiger.engineConfig.cacheSizeGB and—wiredTigerCacheSizeGB. Avoid increasing the WiredTigerinternal cache size above its default value.

Note

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

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

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

If you run mongod in a container (e.g. lxc,cgroups, Docker, etc.) that does not have access to all of theRAM available in a system, you must set storage.wiredTiger.engineConfig.cacheSizeGB to a valueless than the amount of RAM available in the container. The exactamount depends on the other processes running in the container. SeememLimitMB.

To view statistics on the cache and eviction rate, see thewiredTiger.cache fieldreturned from the serverStatus command.

Compression and Encryption

When using encryption, CPUs equipped with AES-NI instruction-setextensions show significant performance advantages.If you are using MongoDB Enterprise with theEncrypted Storage Engine, choose a CPU that supports AES-NI forbetter performance.

See also

Concurrency

Use Solid State Disks (SSDs)

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

Use SSD if available and economical.

Commodity (SATA) spinning drives are often a good option, as therandom I/O performance increase with more expensive spinning drivesis not that dramatic (only on the order of 2x). Using SSDs orincreasing 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) cancause a number of operational problems, including slow performance forperiods of time and high system process usage.

When running MongoDB servers and clients on NUMA hardware, you should configurea 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 version2.0) and Windows (since version 2.6) machines. If theNUMA configuration may degrade performance, MongoDB prints a warning.

See also

• The MySQL “swap insanity” problem and the effects of NUMApost, which describes the effects ofNUMA on databases. The post introduces NUMA and its goals, andillustrates how these goals are not compatible with productiondatabases. Although the blog post addresses the impact of NUMA forMySQL, the issues for MongoDB are similar.
• NUMA: An Overview.

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 thesysctl 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 yourmongod instances, including the config servers, mongos instances, and any clients.If you do not have the numactl command, refer to the documentation foryour operating system to install the numactl package.

The following operation demonstrates how to start a MongoDB instanceusing 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 moreinformation, see the Documentation for /proc/sys/vm/*.

Disk and Storage Systems

Swap

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

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

RAID

For optimal performance in terms of the storage layer, use disksbacked by RAID-10. RAID-5 and RAID-6 do not typically providesufficient performance to support a MongoDB deployment.

Remote Filesystems

With the WiredTiger storage engine, WiredTiger objects may be stored onremote file systems if the remote file system conforms to ISO/IEC9945-1:1996 (POSIX.1). Because remote file systems are often slowerthan local file systems, using a remote file system for storage maydegrade 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’saccess and write pattern. Mount the components as separate filesystemsand use symbolic links to map each component’s path to the devicestoring it.

For the WiredTiger storage engine, you can also store the indexes on adifferent storage device. Seestorage.wiredTiger.engineConfig.directoryForIndexes.

Note

Using different storage devices will affect your ability to createsnapshot-style backups of your data, since the files will be ondifferent devices and volumes.

Scheduling

Scheduling for Virtual or Cloud Hosted Devices

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

Scheduling for Physical Servers

For physical servers, the operating system should use a deadline_scheduler. The _deadline scheduler caps maximum latency per requestand maintains a good disk throughput that is best for disk-intensivedatabase applications.

Architecture

Replica Sets

See the Replica Set Architecturesdocument for an overview of architectural considerations for replicaset deployments.

Sharded Clusters

See Sharded Cluster Production Architecture for anoverview of recommended sharded cluster architectures for productiondeployments.

See also

Development Checklist

Compression

WiredTiger can compress collection data using one of the followingcompression library:

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

By default, WiredTiger uses snappy compression library. Tochange the compression setting, seestorage.wiredTiger.collectionConfig.blockCompressor.

WiredTiger uses prefix compression on all indexes by default.

Clock Synchronization

MongoDB components keep logical clocks forsupporting time-dependent operations. Using NTPto synchronize host machine clocks mitigates the risk of clock driftbetween components. Clock drift between components increases thelikelihood of incorrect or abnormal behavior of time-dependentoperations like the following:

• If the underlying system clock of any given MongoDBcomponent drifts a year or more from other components in the samedeployment, communication between those members may become unreliableor halt altogether.

The maxAcceptableLogicalClockDriftSecs parameter controlsthe amount of acceptable clock drift between components. Clusters witha lower value of maxAcceptableLogicalClockDriftSecs have acorrespondingly lower tolerance for clock drift.

• Two cluster members with different system clocks may returndifferent values for operations that return the currentcluster or system time, such as Date(),NOW, and CLUSTER_TIME.

• Features which rely on timekeeping may have inconsistent orunpredictable behavior in clusters with clock drift between MongoDBcomponents.

For example, TTL indexes relyon the system clock to calculate when to delete a given document. Iftwo members have different system clock times, each member coulddelete a given document covered by the TTL index at a differenttime. Since Client Sessions and Causal Consistency Guarantees use TTL indexes to control theirlifespan, clock drift could result in inconsistent or unpredictablesession timeout behavior.

NTP synchronization is required for deployments running MongoDB lowerthan 3.4.6 or 3.2.17 with the Wired Tiger storage engine, whereclock drift could lead to checkpoint hangs. The issuewas fixed in MongoDB 3.4.6+ and MongoDB3.2.17+, and is resolved in all pointrelease of MongoDB 3.6, 4.0, and 4.2.

Platform Specific Considerations

MongoDB on Linux

Kernel and File Systems

When running MongoDB in production on Linux, you should use Linuxkernel 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, usingXFS is strongly recommended for data bearing nodes to avoidperformance issues that may occur when using EXT4 with WiredTiger.

• In general, if you use the XFS file system, use at least version2.6.25 of the Linux Kernel.
• If you use the EXT4 file system, use at least version2.6.28 of the Linux Kernel.
• On Red Hat Enterprise Linux and CentOS, use at least version2.6.18-194 of the Linux kernel.

System C Library

MongoDB uses the GNU C Library(glibc) on Linux. Generally, each Linux distro provides its ownvetted version of this library. For best results, use the latest updateavailable for this system-provided version. You can check whether you havethe latest version installed by using your system’s package manager. Forexample:

• On RHEL / CentOS, the followingcommand updates the system-provided GNU C Library:

sudo yum update glibc

• On Ubuntu / Debian, the following command updates the system-providedGNU C Library:

sudo apt-get install libc6

fsync() on Directories

Important

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

Set vm.swappiness to 1

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

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

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

To see what the current swappiness level is, run:

cat /proc/sys/vm/swappiness

To change swappiness while the system is running, run:

sysctl vm.swappiness=1

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

vm.swappiness = 1

Recommended Configuration

For all MongoDB deployments:

• Use the Network Time Protocol (NTP) to synchronize time amongyour hosts. 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 databasefiles.

• Set the file descriptor limit, -n, and the user process limit(ulimit), -u, above 20,000, according to the suggestions in theulimit reference. A low ulimit will affectMongoDB when under heavy use and can produce errors and lead tofailed connections to MongoDB processes and loss of service.

• Disable Transparent Huge Pages. MongoDB performs better withnormal (4096 bytes) virtual memory pages. See Transparent HugePages Settings.

• Disable NUMA in your BIOS. If that is not possible, seeMongoDB on NUMA Hardware.

• Configure SELinux for MongoDB if you are not using thedefault MongoDB directory paths or ports.

See: Configure SELinux forMongoDB and Configure SELinuxfor MongoDB Enterprisefor the required configuration.

Note

If you are using SELinux, any MongoDB operation that requiresserver-side JavaScript willresult in segfault errors. Disable Server-Side Execution of JavaScript describeshow to disable execution of server-side JavaScript.

For the WiredTiger storage engine:

• Set the readahead setting between 8 and 32 regardless of storagemedia type (spinning disk, SSD, etc.).

Higher readahead commonly benefits sequential I/O operations.Since MongoDB disk access patterns are generally random, using higherreadahead settings provides limited benefit or potential performancedegradation. As such, for optimal MongoDB performance, setreadahead between 8 and 32, unless testing shows a measurable,repeatable, and reliable benefit in a higher readahead value.MongoDB commercial support canprovide advice and guidance on alternate readahead configurations.

MongoDB and TLS/SSL Libraries

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

<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 differentfrom the TLS/SSL libraries that the mongod was compiled against.Typically these messages do not require intervention; however, you canuse the following operations to determine the symbol versions thatmongod 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 thefollowing 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 symbolname. Compare these values with the values returned by the followingoperations 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 bymongod from the libcrypto library do not begin withCRYPTO_.

MongoDB on Windows

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

MongoDB on Virtual Environments

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

For all platforms, consider Scheduling.

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 eitherconfiguration, you should:

• Enable AWSEnhanced Networkingfor your instance. Not all instance types support Enhanced Networking.

To learn more about Enhanced Networking, see to theAWS documentation.

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

• Use provisioned IOPSfor the storage, with separate devices for journal and data. Do notuse the ephemeral (SSD) storage availableon most instance types as their performance changes moment to moment.(The i series is a notable exception, but very expensive.)

• Disable DVFS andCPU power saving modes.

See also

Amazon documentation on Processor State Control

• Disable hyperthreading.

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 betterperformance when using Premium storage than it does with Standardstorage.

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

Note

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

• To view the keepalive setting on Linux, use one of the followingcommands:

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, thetcp_keepalive_time value applies to both IPv4 and IPv6.

• To change the tcpkeepalive_time value, you can use one of thefollowing commands, supplying a _ in seconds:

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 persistthe setting, add the following line to /etc/sysctl.conf,supplying a in seconds, and reboot the machine:

net.ipv4.tcp_keepalive_time = <value>

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

• To view the keepalive setting on Windows, 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 or0x6ddd00 in hexadecimal.

• To change the KeepAliveTime value, use the following command inan Administrator Command Prompt, where <value> isexpressed 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 onKeepAliveTime formore information on setting keepalive for MongoDB deployments onWindows systems. Keepalive values greater than or equal to600000 milliseconds (10 minutes) will be ignored bymongod and mongos.

VMware

MongoDB is compatible with VMware.

VMware supports memory overcommitment, where you can assign more memoryto your virtual machines than the physical machine has available. Whenmemory is overcommitted, the hypervisor reallocates memory between thevirtual machines. VMware’s balloon driver (vmmemctl) reclaims thepages 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 guestapplications, which can interfere with MongoDB’s memory management andaffect MongoDB’s performance.

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

Ensure that virtual machines stay on a specific ESX/ESXi host bysetting VMware’s affinity rules.If you must manually migrate a virtual machineto another host and the mongod instance on the virtual machine is theprimary, you must first step down the primary and thenshut down the instance.

Follow the networking best practices for vMotionand the VMKernel.Failure to follow the best practices can result in performance problemsand affect replica set andsharded cluster highavailability mechanisms.

It is possible to clone a virtual machine running MongoDB.You might use this function tospin up a new virtual host to add as a member of a replicaset. If you clone a VM with journaling enabled, the clone snapshot willbe 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 memoryto your virtual machines than the physical machine has available. Whenmemory is overcommitted, the hypervisor reallocates memory between thevirtual machines. KVM’s balloon driver reclaims thepages 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 guestapplications, which can interfere with MongoDB’s memory management andaffect MongoDB’s performance.

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

Performance Monitoring

Note

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

iostat

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

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

iostat -xmt 1

Key fields from iostat:

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

bwm-ng

bwm-ng is acommand-line tool for monitoring network use. If you suspect anetwork-based bottleneck, you may use bwm-ng to begin yourdiagnostic process.

Backups

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