Some Considerations Related To Mongo DB

Post date: Jan 6, 2013 11:38:36 AM

There are some general aspects regarding Mongo that raise some questions and the corresponding answers can be summarized in some basic, easy to follow rules:

1) If you ask yourself about hardware sizing with respect to memory then consider an amount of RAM at least equal to the amount of mapped memory exhibited by the mongod process as delivered by the mongostat output. In case journaling is enabled the amount of virtual memory will be doubled in comparison to the mapped memory and this should be regarded as normal behaviour but if journaling is not enabled and the difference between virtual memory and mapped memory increases then this might indicate a memory leak. If the amount of RAM is less than the mapped memory then mongod accesses the HDD and page faults might incur. In general an increasing amount of page faults indicate a need

to redesign and taking sharding into consideration or a need to increase the amount of RAM memory if this is deemed as possible.

2) An odd number of votes is highly recommended in case of failover scenarios linked to multi data center deployments because they assure the automatic election of a primary in case of network partitions and other single or double points of failure encountered either in a single data center or in all of them. Although votes can be changed explicitly by altering the relica set configuration on the primary this is not recommended as intermittent ties and possibly deadlocks might appear. The cheapest solution in this case would be the addition of a sufficient number of arbiters.