Most of you might find these names similar to two popular Unix commands, iostat and top. For MongoDB, mongostat and mongotop are two utilities which does pretty much the same job as these two Unix commands do and there is no prize for guessing that these are used to monitor the mongo instance.
In this recipe, we would be simulating some operations on a standalone mongo instance by running a script that would attempt to keep your server busy, and then in another terminal we will run 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. If you are not aware how to start a standalone server, refer to Installing single node MongoDB in Chapter 1, Installing and Starting the Server. We also need to download the script KeepServerBusy.js from Packt site and keep it handy for execution on 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. These two utilities mongostat and mongotop comes standard with the mongo installation.
- Start the MongoDB server, and let it listen to the default port for connections.
- In a separate terminal, execute the provided JavaScript
KeepServerBusy.jsas 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 provided JavaScript
KeepServerBusy.jswas executed to stop the operation that keeps the server busy.
Let's see what we have captured from these two utilities.
We start by analyzing mongostat. On my laptop, the capture using mongostat looks like this:
mongostat connected to: 127.0.0.1 insert query update delete getmore command flushes mapped vsize res faults idx miss % qr|qw ar|aw netIn netOut conn time 1000 1 950 1000 1 1|0 0 624.0M 1.4G 50.0M 0 0 0|0 0|1 431k 238k 2 08:59:21 1000 1 1159 1000 1 1|0 0 624.0M 1.4G 50.0M 0 0 0|0 0|0 468k 252k 2 08:59:22 1000 1 984 1000 1 1|0 0 624.0M 1.4G 50.0M 0 0 0|0 0|1 437k 240k 2 08:59:23 1000 1 1066 1000 1 1|0 0 624.0M 1.4G 50.0M 0 0 0|0 0|1 452k 246k 2 08:59:24 1000 1 944 1000 1 2|0 0 624.0M 1.4G 50.0M 0 0 0|0 0|1 431k 237k 2 08:59:25 1000 1 1149 1000 1 1|0 0 624.0M 1.4G 50.0M 0 0 0|0 0|1 466k 252k 2 08:59:26 1000 2 1015 1053 2 1|0 0 624.0M 1.4G 50.0M 0 0 0|0 0|0 450k 293k 2 08:59:27
You may choose to look at what the script KeepServerBusy.js is doing to keep the server busy. All it does is insert 1000 documents in collection monitoringTest, then update them one by one to set a new key in it, executes a find and iterates through all of them, and finally deletes them one by one and is basically a write intensive operation.
The output does look ugly with content wrapping, but let's analyze the fields one by one and see what the fields to keep an eye on.
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 a primary and secondary instance and see different stats captured.
Apart from mongostat, we also used the mongotop utility to capture the stats. Let's 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 see in this stat. We see the total time a database was busy reading or writing in the given slice of 1 second. The value given in the total would be sum of the read and the write time. If we actually compare the mongotop and mongostat for the same time slice, the percentage of time duration for which the write was taking place would be very close to the figure given in the percentage time that the database was locked in the mongostat output.
The command mongotop 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 opposed to the default value of 1 second.
- In the recipe Getting current executing operations and killing them, we will see how to get the current executing operations from the shell and kill them if needed
- In the recipe Using profiler to profile operations, we will see how to use the inbuilt profiling feature of Mongo to log operation execution times.