Best Practices Dashboard

The VividCortex application automatically reviews the settings of your OS and database instances and identifies settings which are inconsistent with established best practices. The Best Practices dashboard displays the results of these tests, allowing you to quickly find areas where you can improve the performance and security of your database. These checks are performed every 15 minutes.

Right now, this feature is available for MongoDB databases, and is in private beta. Contact Customer Support at support@vividcortex.com if you are interested in participating.

To visit the Best Practices dashboard, click on the “Health” icon in the left-hand navigation. Then at the top of the window, click “Best Practices.”

Best Practices Dashboard

The Best Practices page lists all of the checks which one or more of your database instances are currently failing (you can also see checks which have passed by clicking “Show closed Best Practices”). To view specific Best Practices and which instances have failed a check, click one of the Categories, and then click one of the Types to expand. For example, in this screenshot, there are three Categories, and the first Category is expanded to show three Types:

Best Practices Dashboard

Click on one of the Types to see a list of instances which have failed that check:

Best Practices Dashboard

Below you will find a list of checks for each database technology.

MongoDB Checks

These checks are based on the official MongoDB documentation, which makes a number of configuration recommendations. Each of the “Reference Source” links in the table below are links to the MongoDB documentation for further reading.

MongoDB & OS Configuration

Check Description Official Documentation
Transparent huge pages Transparent huge pages should be disabled on the server, as MongoDB generally performs better with normally sized virtual memory pages. Reference Source
Journaling Journaling should be enabled on the server to help avoid data loss in the case of a crash. Reference Source
Swap MongoDB recommends having some swap space configured to help avoid getting terminated by the OOM Killer when the server is under memory pressure. Reference Source
TCP keepalive MongoDB recommends having a short keepalive time set for network connections, as this results in generally better performance for replica sets and sharded clusters. Reference Source
Self resolution When running in a replica set, it is important to ensure that the MongoDB server can resolve its own hostname. Reference Source
Filehandle limit Ensure that MongoDB has enough file handles to handle your workload. For production systems a limit of 98,000 is usually reasonable. Reference Source
Thread limit Ensure the server has a high enough thread limit for your workload. For production systems a limit of 64,000 is usually reasonable. Reference Source
PID limit Ensure that the server has a high enough PID limit for your workload. For production systems a limit of 64,000 is usually reasonable. Reference Source
Readahead settings Ensure the readahead settings for your storage device are appropriate; if using WiredTiger, readahead should be set to 0. For MMAPv1, consider a value of 32 or lower. Reference Source
Disk scheduler Use the noop or deadline disk scheduler for the database’s storage device for maximum performance. Reference Source
dbPath mount point Use noatime for the dbPath mount point to improve performance. Reference Source
Filesystem The XFS filesystem is recommended with MongoDB as it provides generally better performance. For WiredTiger it is strongly recommended due to known performance problems with EXT4. Reference Source
Index sizes Ensure that each of your indexes fit entirely in memory so that the system can avoid reading the index from disk. Reference Source
Index total size Ensure that all your indexes fit entirely in memory so that the system can avoid reading the index from disk. Reference Source
Collection sizes MongoDB recommends your working set should stay in memory to achieve good performance. Reference Source
Total size MongoDB recommends the total size of your collections should stay in memory to achieve good performance. Reference Source

MongoDB Replication Configuration

Check Description Official Documentation
Hostnames Use hostnames when configuring replica set members rather than IP-addresses, as it makes them easier to maintain in production. Reference Source
Cluster voting members Ensure that the replica set has an odd number of voting members; otherwise during an election it may not be possible to reach a quorum successfully. Reference Source
Cluster vote config It is recommended that replica set members have either 0 or 1 votes allocated to them. Reference Source

MongoDB Security Configuration

Check Description Official Documentation
Authorization Ensure that MongoDB is configured with role-based access control enabled so that specific user actions can be limited as necessary. Reference Source
Encryption MongoDB enterprise edition supports at-rest encryption for the WiredTiger storage engine. Enabling this option is recommended to limit the possibility of data theft. Reference Source
Network exposure Ensure that MongoDB’s HTTP status interface, REST API and JSON API are disabled to limit untrusted access to the database. Reference Source
Javascript MongoDB supports the execution of JavaScript code for certain server operations; this should be disabled if possible to avoid unsafe use. Reference Source