Database Reference
In-Depth Information
The main columns of interest are the first six columns, which show the rate at which the
mongod
server is handling
certain operations (for example, insert or query). Other columns worth keeping an eye on when diagnosing problems
with your installation include the following:
Pagefaults:
Represents when your MongoDB instance needs to read data from disk in order
to fulfill queries. This is normally an indicator of suboptimal performance and that all the data
you normally need for your day-to-day operations can't be held within the RAM available
to MongoDB. You should check to see if there are any queries that may be scanning all your
documents and not using indexes, or you may need to move to a server with more available RAM.
•
•
queues
: Represents the number of operations queued up waiting for their turn to execute. As
MongoDB allows one writer (inserts, updates and deletes) and many readers (finds), this can
lead to a situation where read queries are being blocked by poorly performing writes. Worse
still, you can wind up in situations where you have a number of reads and writes blocked by one
poorly performing write. Check to see which queries may be blocking the others from executing.
•
% locked
: Shows the percentage of time a given collection had its write lock taken out. A very
high number here indicates that you are performing one or more write operations running
for nearly the whole time window. A high
% locked
will likely impact the performance of all
queries. Check to see if you have poorly performing writes or if your system is page-faulting,
which may indicate the need for more RAM. This could also be related to schema issues such
as very large arrays in documents, and remember that prior to MongoDB 2.2 locking was
done at the per-instance level, so upgrading may help lower this value with the more recent
concurrency improvements.
rOLLING YOUr OWN Stat MONItOrING tOOL
much of the information provided by
mongostat
is the same information that you can get from the
db.serverStatus()
call. it would not be a big task to create a service that uses this api to poll the server every
few seconds and then places the results into a mongoDb collection.
the application of a few indexes, some carefully crafted queries, and a graphing package would enable you to
use such a simple real-time monitor to produce historical logs.
there are also many third-party adapters available for mongoDb that let you use common open source
or commercial monitoring systems, including tools such as nagios, Ganglia, and Cacti. as mentioned
previously, the mongoDb manual includes a page on its website that shares the latest information
about monitoring interfaces available for mongoDb (for more information on this topic, see
Using the MongoDB Management Service (MMS)
Most of the statistical information discussed so far is also available via the MongoDB Management Service, also
known as MMS. MMS is a monitoring service provided by MongoDB, Inc. It provides an agent you can install on a
local machine. Once it is installed, you can add your servers via the MMS web page in order to instruct the agent to
monitor them. Once monitoring has begun, you can then dive into specific hosts to see graphs of the performance
statistics for that MongoDB instance. You can monitor everything from individual MongoDB instances to replica
sets, right up to full sharded clusters, including config servers and MongoS. MMS also has facilities to view all the
individual members of these groups or to view aggregated statistics for each. You can then configure alerts to be sent
