In General, page faults will occur when the database fails to read data from RAM, so it is forced to read off of the physical disk. Now MongoDB page faults occur when the database fails to read data from virtual memory and must read the data from the physical disk. Most databases cache data in RAM as often as possible to avoid having to read from physical disks since it is slow and costs you valuable time. We all wish, that all of our data would be stored in RAM, but that’s extremely expensive and usually infeasible, so the database will inevitably need to read from disk.
Now, depending on the version of MongoDB, that you’re running, the storage engine you will be using is either MMAPv1 or WiredTiger. MMAPv1 was MongoDB’s original storage engine until 3.2, which was then replaced by WiredTiger as the default storage engine, and has been officially deprecated as of the release of 4.2. This blog mainly focuses on MMAPv1 since it is an older, deprecated technology and page faults are not tracked as a relevant statistic in WiredTiger.
The older versions of MongoDB use memory to manage documents, indexes in memory and then has MMAPv1 translate these files to virtual memory. MMAPv1 uses memory-mapped files to read data from virtual memory through a
mmap () syscall. Since MMAPv1 relies heavily on virtual memory for its processes, it is prone to page faults as there is a limited amount of space to cache data to virtual memory.
As mentioned in our previous MongoDB troubleshooting blogs, just like database locking, and replication lag, MongoDB page faults are a common occurrence in your MongoDB Database (in MMAPv1), but if they begin to happen consistently, or at a higher than normal volume, then you may need to take action. MongoDB Page faults are usually indicative of a deeper problem within your system. Due to it being an older technology, MongoDB page faults will occur more often in MMAPv1. Some of its constraints are a lack of data compression options, using all of its free memory to cache, and its inability to scale, which all relates back to not enough available RAM to read off of. MongoDB page faults may also happen due to unindexed queries, and this may be the root cause if you are noticing a high ratio of page faults compared to operations, usually a 1:1 ratio or higher.
Now that you know what causes Page Faults to happen and what the underlying problem could be, its time to stop them from happening too often!
Ideally, in a perfect world, you would be able to completely stop MongoDB page faults from ever happening again… sadly, we don’t live in a perfect world, so your best hope is to minimize their occurrence. Since you know that there are a few causes for MongoDB page faults, then you can expect that there are a few different methods in preventing them. Since MMAPv1’s performance relies heavily on the amount of RAM available and caching data in the virtual memory, the first and foremost preventative measure you will want to take is to monitor the amount of RAM that your systems have available for use. You can use Mongostat, which allows you to get stats returned to you from MongoDB, including page faults. MongoStat is a pretty basic monitoring tool, that won’t give you much insight into why problems are arising. You may want to consider setting up a more comprehensive monitoring system for your entire environment with services like Google Cloud Monitoring and Logging, or New Relic monitoring.
Using a more comprehensive monitoring solution can allow you to stay on top of the problem and be proactive, instead of reactive. BindPlane can be implemented with these monitoring services and will let you monitor and set up alerts for metrics relevant to Page faults including, file size, index size, the number of indexes, Memory usage (mapped, resident, virtual) and a lot more, you can find the rest in our MongoDB for Stackdriver docs.
Along with monitoring the relevant metrics of MongoDB page faults, you can also make sure your data is configured into working sets that fit into memory and won’t use more RAM than required. You should also make sure your data is indexed in MongoDB correctly. Indexing is very important when it comes to executing queries efficiently. When your data isn’t indexed, it will take more RAM to access your data and could push page faults if there isn’t enough available in your environment. Visit the MongoDB docs on indexing to learn more about properly indexing your data.
Now unless there are extenuating circumstances, if you are using MMAPv1, you might want to consider upgrading to the newest version of MongoDB and jump to WiredTiger. It could be difficult to migrate all of your data to a new engine, but in the long run, it is worth the upgrade now that MMAPv1 has been deprecated and is no longer supported by MongoDB.