If globalLock.currentQueue.total is consistently high, then there is a chance that a large number of re- quests 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 page faults (page 214) and disk reads. 

## Memory and the MMAPv1 Storage Engine 

Memory Use With the MMAPv1 (page 91) storage engine, MongoDB uses memory-mapped files to store data. Given a data set of sufficient size, the mongod process will allocate all available memory on the system for its use. 

While this is intentional and aids performance, the memory mapped files make it difficult to determine if the amount of RAM is sufficient for the data set. 

The memory usage statuses metrics of the serverStatus output can provide insight into MongoDB’s memory use. 

The mem.resident field provides the amount of resident memory in use. If this exceeds the amount of system memory and there is a significant amount of data on disk that isn’t in RAM, you may have exceeded the capacity of your system. 

You can inspect mem.mapped to check the amount of mapped memory that mongod is using. If this value is greater than the amount of system memory, some operations will require a page faults to read data from disk. 

Page Faults With the MMAPv1 storage engine, page faults can occur as MongoDB reads from or writes data to parts of its data files that are not currently located in physical memory. In contrast, operating system page faults happen when physical memory is exhausted and pages of physical memory are swapped to disk. 

MongoDB reports its triggered page faults as the total number of page faults in one second. To check for page faults, see the extra_info.page_faults value in the serverStatus output. 

Rapid increases in the MongoDB page fault counter may indicate that the server has too little physical memory. Page faults also can occur while accessing large data sets or scanning an entire collection. 

A single page fault completes quickly and is not problematic. However, in aggregate, large volumes of page faults typically indicate that MongoDB is reading too much data from disk. 

MongoDB can often “yield” read locks after a page fault, allowing other database processes to read while mongod loads the next page into memory. Yielding the read lock following a page fault improves concurrency, and also improves overall throughput in high volume systems. 

Increasing the amount of RAM accessible to MongoDB may help reduce the frequency of page faults. If this is not possible, you may want to consider deploying a sharded cluster or adding shards to your deployment to distribute load among mongod instances. 

See What are page faults? (page 775) for more information. 

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

• globalLock.activeClients contains a counter of the total number of clients with active operations in progress or queued. 

• connections is a container for the following two fields: 

