MongoDB Documentation, Release 3.0.4 • The operating system’s cache strategy for LRU (Least Recently Used) • The impact of journaling (page 308) • The number or rate of page faults and other MongoDB Cloud Manager gauges to detect when you need more RAM • Each database connection thread will need up to 1 MB of RAM. • choosing an appropriate shard key (page 674) and • sufficient capacity to support current and future operations (page 671). MongoDB defers to the operating system when loading data into memory from disk. It simply memory maps (page 773) all its data files and relies on the operating system to cache data. The OS typically evicts the least- recently-used data from RAM when it runs low on memory. For example if clients access indexes more frequently than documents, then indexes will more likely stay in RAM, but it depends on your particular usage. To calculate how much RAM you need, you must calculate your working set size, or the portion of your data that clients use most often. This depends on your access patterns, what indexes you have, and the size of your documents. Because MongoDB uses a thread per connection model, each database connection also will need up to 1MB of RAM, whether active or idle. If page faults are infrequent, your working set fits in RAM. If fault rates rise higher than that, you risk performance degradation. This is less critical with SSD drives than with spinning disks. Because mongod uses memory-mapped files (page 773), the memory statistics in top require interpretation in a special way. On a large database, VSIZE (virtual bytes) tends to be the size of the entire database. If the mongod doesn’t have other processes running, RSIZE (resident bytes) is the total memory of the machine, as this counts file system cache contents. For Linux systems, use the vmstat command to help determine how the system uses memory. On OS X systems use vm_stat . You can prevent most issues encountered with sharding by ensuring that you choose the best possible shard key for your deployment and ensure that you are always adding additional capacity to your cluster well before the current resources become saturated. Continue reading for specific issues you may encounter in a production environment. Your cluster must have sufficient data for sharding to make sense. Sharding works by migrating chunks between the shards until each shard has roughly the same number of chunks. The default chunk size is 64 megabytes. MongoDB will not begin migrations until the imbalance of chunks in the cluster exceeds the migration threshold (page 685). While the default chunk size is configurable with the chunkSize setting, these behaviors help prevent unnecessary chunk migrations, which can degrade the performance of your cluster as a whole. If you have just deployed a sharded cluster, make sure that you have enough data to make sharding effective. If you do not have sufficient data to create more than eight 64 megabyte chunks, then all data will remain on one shard. Either lower the chunk size (page 688) setting, or add more data to the cluster. 782 Chapter 11. Frequently Asked Questions How do I read memory statistics in the UNIX top command 11.9.5 Sharded Cluster Diagnostics In a new sharded cluster, why does all data remains on one shard? The two most important factors in maintaining a successful sharded cluster are: