MongoDB Performance
On this page
As you develop and operate applications with MongoDB, you may need to analyze the performance of the application and its database. When you encounter degraded performance, it is often a function of database access strategies, hardware availability, and the number of open database connections.
Some users may experience performance limitations as a result of inadequate or inappropriate indexing strategies, or as a consequence of poor schema design patterns. Locking Performance discusses how these can impact MongoDB's internal locking.
Performance issues may indicate that the database is operating at capacity and that it is time to add additional capacity to the database. In particular, the application's working set should fit in the available physical memory.
In some cases performance issues may be temporary and related to abnormal traffic load. As discussed in Number of Connections, scaling can help relax excessive traffic.
Database Profiler can help you to understand what operations are causing degradation.
Locking Performance
MongoDB uses a locking system to ensure data set consistency. If certain operations are long-running or a queue forms, performance will degrade as requests and operations wait for the lock.
Lock-related slowdowns can be intermittent. To see if the lock has been
affecting your performance, refer to the locks
section and the globalLock section of the
serverStatus output.
Note
Some serverStatus response fields are not returned on
MongoDB Atlas M0/M2/M5 clusters. For more information, see
Limited Commands in the MongoDB Atlas
documentation.
Dividing locks.<type>.timeAcquiringMicros by
locks.<type>.acquireWaitCount
can give an approximate average wait time for a particular lock mode.
locks.<type>.deadlockCount provide
the number of times the lock acquisitions encountered deadlocks.
If globalLock.currentQueue.total is consistently high,
then there is a chance that a large number of requests are waiting for
a lock. This indicates a possible concurrency issue that may be affecting
performance.
If globalLock.totalTime is
high relative to uptime, the database has
existed in a lock state for a significant amount of time.
Long queries can result from ineffective use of indexes; non-optimal schema design; poor query structure; system architecture issues; or insufficient RAM resulting in disk reads.
Number of Connections
In some cases, the number of connections between the applications and the
database can overwhelm the ability of the server to handle requests. The
following fields in the serverStatus document can provide insight:
connectionsis a container for the following two fields:connections.currentthe total number of current clients connected to the database instance.connections.availablethe total number of unused connections available for new clients.
If there are numerous concurrent application requests, the database may have trouble keeping up with demand. If this is the case, then you will need to increase the capacity of your deployment.
For write-heavy applications, deploy sharding and add one or more
shards to a sharded cluster to distribute load among
mongod instances.
Spikes in the number of connections can also be the result of application or driver errors. All of the officially supported MongoDB drivers implement connection pooling, which allows clients to use and reuse connections more efficiently. An extremely high number of connections, particularly without corresponding workload, is often indicative of a driver or other configuration error.
Self-Managed Connection Limits
Unless constrained by system-wide limits, the maximum number of
incoming connections supported by MongoDB is configured with the
maxIncomingConnections setting. On Unix-based systems,
system-wide limits can be modified using the ulimit command, or by
editing your system's /etc/sysctl file. See UNIX ulimit Settings for Self-Managed Deployments
for more information.
MongoDB Atlas Connection Limits
MongoDB Atlas sets the limit for concurrent incoming connections based on the cluster tier and class. To learn more, see Connection Limits and Cluster Tier in the Atlas documentation.