Most of you might find these names similar to two popular Unix commands, iostat and top. For MongoDB, mongostat and mongotop are two utilities that do pretty much the same job as the two Unix commands, and there is no prize for guessing that these are used to monitor the Mongo instance.
In this recipe, we will be simulating some operations on a standalone Mongo instance by running a script that will attempt to keep your server busy; then, in another terminal, we will be running these utilities to monitor the db instance.
You need to start a standalone server listening to any port for client connections; in this case, we will stick to the default 27017. In case you are not aware of how to start a standalone server, refer to the Single node installation of MongoDB recipe in Chapter 1, Installing and Starting the MongoDB Server. We also need to download the KeepServerBusy.js script from the book's website and keep it handy for execution on the local drive. Also, it is assumed that the bin directory of your Mongo installation is present in the path variable of your operating system. If not, then these commands need to be executed with the absolute path of the executable from the shell. The mongostat and mongotop utilities come as standard with the Mongo installation.
Let's take a look at the steps in detail:
- Start the MongoDB server. Let it listen to the default port for connections.
- In a separate terminal, execute the
KeepServerBusy.jsJavaScript as follows:$ mongo KeepServerBusy.js --quiet - Open a new OS terminal and execute the following command:
$ mongostat - Capture the output content for some time and then hit Ctrl + C to stop the command from capturing more stats. Keep the terminal open or copy the stats to another file.
- Now execute the following command from the terminal:
$ mongotop - Capture the output content for some time and then hit Ctrl + C to stop the command from capturing more stats. Keep the terminal open or copy the stats to another file.
- Hit Ctrl + C in the shell, where the
KeepServerBusy.jsJavaScript was executed, to stop the operation that keeps the server busy.
Let us see what we have captured from these two utilities. We start by analyzing mongostat. On my laptop, the output of the $ mongostat command is as follows:
$ mongostat connected to: 127.0.0.1 insert query update delete getmore command flushes mapped vsize res faults locked db idx miss % qr|qw ar|aw netIn netOut conn time 1000 1 1000 1794 1 1|0 0 320m 808m 54m 37 test:85.7% 0 0|0 0|1 271k 94k 2 23:24:30 2000 1 1326 1206 1 1|0 0 320m 808m 54m 113 test:83.3% 0 0|0 0|1 339k 51k 2 23:24:31 1000 1 952 1000 1 1|0 0 320m 808m 54m 28 test:84.4% 0 0|0 0|1 219k 51k 2 23:24:32 77 1 722 1000 1 1|0 0 320m 808m 54m 87 test:73.0% 0 0|0 0|1 131k 51k 2 23:24:33 923 1 1000 792 1 1|0 0 320m 808m 54m 42 test:83.3% 0 0|0 0|0 206k 51k 2 23:24:34 1000 1 1000 934 1 1|0 0 320m 808m 54m 150 test:84.6% 0 0|0 0|1 220k 51k 2 23:24:35 1000 1 1000 920 1 1|0 0 320m 808m 54m 13 test:84.9% 0 0|0 0|1 219k 51k 2 23:24:36
You may choose to look at what the KeepServerBusy.js script is doing to keep the server busy. All it does is insert 1000 documents in the monitoringTest collection; update them one by one to set a new key in them; execute a find and iterate through all of them; and finally, delete them one by one. Basically, it is a write-intensive operation.
The output does look ugly with the content wrapping, but let us analyze the fields one by one and see what to look out for. The following table gives a description of each column:
There are some more fields seen if mongostat is connected to a replica set primary or secondary. As an assignment, once the stats or a standalone instance are collected, start a replica set server and execute the same script to keep the server busy. Use mongostat to connect to primary and secondary instances and see if different stats are captured.
Apart from mongostat, we also used the mongotop utility to capture the stats. Let us see its output and make some sense out of it:
$ mongotop connected to: 127.0.0.1 ns total read write 2014-01-15T17:55:13 test.monitoringTest 899ms 1ms 898ms test.system.users 0ms 0ms 0ms test.system.namespaces 0ms 0ms 0ms test.system.js 0ms 0ms 0ms test.system.indexes 0ms 0ms 0ms ns total read write 2014-01-15T17:55:14 test.monitoringTest 959ms 0ms 959ms test.system.users 0ms 0ms 0ms test.system.namespaces 0ms 0ms 0ms test.system.js 0ms 0ms 0ms test.system.indexes 0ms 0ms 0ms ns total read write 2014-01-15T17:55:15 test.monitoringTest 954ms 1ms 953ms test.system.users 0ms 0ms 0ms test.system.namespaces 0ms 0ms 0ms test.system.js 0ms 0ms 0ms test.system.indexes 0ms 0ms 0ms
There is not much to look at in this stat. We see the total time for which the database was busy reading or writing in the given slice of 1 second. The value given in the total will be the sum of the read and the write time. If we actually compare the mongotop and mongostat utilities for the same time slice, the percentage of time duration for which the write was taking place will be very close to the figure given in the percentage time the database was locked in the mongostat's output.
The mongotop command accepts a parameter on the command line as follows:
$ mongotop 5
In this case, the interval after which the stats will be printed out will be 5 seconds, as against the default value of 1 second.
- The Estimating the working set recipe, to learn how to estimate the working set using the working set estimator command introduced in Mongo 2.4
- The Viewing and killing the currently executing operations recipe, to learn how to get the current executing operations from the shell and kill them if needed
- The Using profiler to profile operations recipe to learn how to use the in-built profiling feature of Mongo to log operation's execution time