Caching

Memory Mapped Storage Engine

This is the current storage engine for MongoDB, and it uses memory-mapped files for all disk I/O.  Using this strategy, the operating system's virtual memory manager is in charge of caching.  This has several implications:

• There is no redundancy between file system cache and database cache: they are one and the same.
• MongoDB can use all free memory on the server for cache space automatically without any configuration of a cache size.
• Virtual memory size and resident size will appear to be very large for the mongod process.  This is benign: virtual memory space will be just larger than the size of the datafiles open and mapped; resident size will vary depending on the amount of memory not used by other processes on the machine.
• Caching behavior such as Least Recently Used (LRU) discarding of pages, and laziness of page writes is controlled by the operating system (the quality of the VMM implementation will vary by OS.)

To monitor or check memory usage see: Checking Server Memory Usage

Memory per connection

A thread is associated with each connection from clients to the database. Each thread has a stack that has a size of a few MB. The unused portions of these stacks can be swapped out by the OS as long as the connections live for a while (would not if connect / operation / disconnect in 2 seconds).

Binary footprint

You can get a feel for the “inherent” memory footprint of Mongo by starting it fresh, with no connections, with an empty /data/db directory and looking at the resident bytes.

See Also

• Checking Server Memory Usage
• The Linux Out of Memory OOM Killer