Database Reference
In-Depth Information
it is needed. Using the free memory total as an indicator of excessive memory consumption is not a good practice,
because a good OS will ensure that there is little or no “free” memory. All of your expensive memory is pressed into
good use through caching or buffering disk I/O. Free memory is wasted memory.
By providing a suitable amount of memory, MongoDB can keep more of the data it needs mapped into memory,
which reduces the need for expensive disk I/O.
In general, the more memory you give to MongoDB, the faster it will run. However, if you have a 2GB database,
then adding more than 2-3GB of memory will not make much difference, because the whole database will sit in
RAM anyway.
Understanding Working Set Size
Now we need to talk about one of the more complex things involved with performance tuning your MongoDB
instance, working-set size. This size represents the amount of data stored in your MongoDB instance that will be
accessed “in the course of regular usage.” That phrase alone should tell you that this is a subjective measure and
something that is hard to get an exact value for.
Despite being hard to quantify, understanding the impact of working set size will help you better optimize your
MongoDB instance. The main precept is that for most installations, only a portion of the data will need to be accessed
as part of regular operations. Understanding what portion of your data you will be working with regularly allows you
to size your hardware correctly and thus improves your performance.
Choosing the Right Database Server Hardware
There is a general pressure to move to lower-power (energy) systems for hosting services. However, many of the
lower-power servers use laptop or notebook components to achieve the lower power consumption. Unfortunately,
lower-quality server hardware can use less expensive disk drives in particular. Such drives are not suited for heavy-
duty server applications because of their disks' low rotation speed, which slows the rate at which data can be
transferred to and from the drive. Also, make sure you use a reputable supplier, one you trust to assemble a system
that has been optimized for server operation. It's also worth mentioning that faster and more modern drives such as
SSDs are available, which will provide a significant performance boost. If you can arrange it, the MongoDB, Inc. team
recommends the use of RAID10 for both performance and redundancy. For those of you in the cloud, getting things
like Provisioned IOPS from Amazon is a great way to improve the performance and reliability of your disks.
If you plan to use replication or any kind of frequent backup system that would have to read across the network
connections, you should consider putting in an extra network card and forming a separate network so the servers can
talk with each other. This reduces the amount of data being transmitted and received on the network interface used to
connect the application to the server, which also affects an application's performance.
Probably the biggest thing to be aware of when purchasing hardware is RAM. Because MongoDB uses
memory-mapped files, having sufficient space to keep necessary data somewhere that it can be accessed quickly is a
great way to ensure high performance. This is where you can link in the working-set concept discussed earlier. Having
an idea of how much data you need to allocate for is the key when looking to purchase hardware. Finally, remember
that you don't need to go out and buy 512GB of RAM and install it on one server; you can spread the data load out
using sharding (discussed in Chapter 12).
Evaluating Query Performance
MongoDB has two main tools for optimizing query performance:
explain()
and the MongoDB Profiler (the profiler). The
profiler is a good tool for finding those queries that are not performing well and selecting candidate queries for further
inspection, while
explain()
is good for investigating a single query, so you can determine how well it is performing.
Those of you familiar with MySQL will probably also be familiar with the use of the slow query log, which helps
you find queries that are consuming a lot of time; MongoDB uses the profiler to provide this capability.
