MongoDB Documentation, Release 3.0.4 Allocate Sufficient RAM and CPU MMAPv1 The MMAPv1 storage engine is not CPU bound due to its concurrency model. As such, increasing the number of cores can help but does not provide significant return. Increasing the amount of RAM accessible to MongoDB may help reduce the frequency of page faults. WiredTiger The WiredTiger storage engine is CPU bound. Specifically, the total number of active threads (i.e. concurrent operations) relative to the number of CPUs can impact performance: The threshold amount depends on your application. You can determine the optimum number of concurrent active operations for your application by experimenting and measuring throughput. The output from mongostat provides statistics on the number of active reads/writes in the ( ar|aw ) column. WiredTiger’s default configuration will use either 1GB or half of the installed physical RAM for cache, whichever is larger. This size is tunable through the storage.wiredTiger.engineConfig.cacheSizeGB setting, and should be large enough to hold your entire working set . The default storage.wiredTiger.engineConfig.cacheSizeGB setting assumes that there is a sin- gle mongod instance per node. If a single node contains multiple instances, then you should adjust the storage.wiredTiger.engineConfig.cacheSizeGB setting to accommodate the working set as well as the other mongod instances. If you run mongod in a container (e.g. lxc , cgroups , Docker, etc.) that does not have access to all of the RAM available in a system, you must set the storage.wiredTiger.engineConfig.cacheSizeGB to a value less than the amount of RAM available in the container. The exact amount depends on the other processes running in the container. Concurrency (page 198) Use Solid State Disks (SSDs) MongoDB has good results and a good price-performance ratio with SATA SSD (Solid State Disk). Use SSD if available and economical. Spinning disks can be performant, but SSDs’ capacity for random I/O operations works well with the update model of MMAPv1. Commodity (SATA) spinning drives are often a good option, as the random I/O performance increase with more expensive spinning drives is not that dramatic (only on the order of 2x). Using SSDs or increasing 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) can cause a number of operational problems, including slow performance for periods of time and high system process usage. When running MongoDB servers and clients on NUMA hardware, you should configure a 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 version 2.0) and Windows (since version 2.6) machines. If the NUMA configuration may degrade performance, MongoDB prints a warning. See also: See also: Chapter 5. Administration 200 • Throughput increases as the number of concurrent active operations increases up to the number of CPUs. • Throughput decreases as the number of concurrent active operations exceeds the number of CPUs by some threshold amount.