The VividCortex application automatically reviews the settings of your OS and database instances and identifies settings which are inconsistent with established best practices. For clients with query samples enabled, VividCortex also proactively alerts you to possible query-writing and index optimizations.
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.
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.”
The Best Practices page lists all of the checks which one or more of your database instances or queries are currently failing (you can also see checks which have passed by clicking “Show closed Best Practices”). To view specific Best Practices and which checks have failed, 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:
Click on one of the Types to see a list of instances which have failed that check:
Below you will find a list of checks for each database technology:
These 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
|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
|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
|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|
VividCortex automatically analyzes captured MySQL queries to see if they fail one or more rules designed to ensure adherence to query-writing best practices. Queries which fail one or more of these checks will be displayed on the Best Practices page. For a complete list of rules which VividCortex uses when examining your database queries, please see this list in the Query Analysis Rules documentation.
PostgreSQL Query Checks
VividCortex automatically analyzes captured PostgreSQL queries to see if they fail one or more rules designed to ensure adherence to query-writing best practices. Queries which fail one or more of these checks will be displayed on the Best Practices page. For a complete list of rules which VividCortex uses when examining your database queries, please see this list in the Query Analysis Rules documentation.