MongoDB Monitoring: db.serverStatus()

By David Mytton,
CEO & Founder of Server Density.

Published on the 29th December, 2010.

Tokyo traffic map

There are a number of built in tools and commands which can be used to get important information from MongoDB but because it is relatively new, it can be difficult to know what you need to be doing from an operational perspective to ensure that everything runs smoothly.

This is the 3rd in a series of 6 posts about MongoDB monitoring based on a talk I gave at the MongoSV 2010 conference. View the series index here.

MongoDB Monitoring dashboard + alerting

We provide a MongoDB monitoring service to keep an eye on the health and performance of your MongoDB database cluster automatically and with alerting. Find out more here.


The server status command provides a lot of different statistics that can help you, like the map of traffic in central Tokyo (above).


Every connection to the database has an overhead. You want to reduce this number by using persistent connections through the drivers. The total number of available connections is determined by the file descriptors, which can be calculated based on this formula:

Total file descriptors needed = ( 1 + Total Nodes ( 3*4) ) * incoming connections

If you run out of available connections then you’ll have a problem, which will look like this in the logs.

On Red Hat systems by default this limit is set at 1024 which can be too low. MongoDB has documentation about this but you can set your limit higher on Red Hat systems by editing the /etc/security/limits.conf file. You also need to set UsePAM to yes in /etc/ssh/sshd_config to have it take effect when you log in as your user.

Index counters

The miss ratio is what you’re looking at here. If you’re seeing a lot of index misses then you need to look at your queries to see if they’re making optimal use of the indexes you’ve created. You should consider adding new indexes and seeing if your queries run faster as a result. You can use the explain syntax to see which indexes queries are hitting, and the total execution time so you can benchmark them before and after.

Background flushing

The server status output allows you to see the last time data was flushed to disk, and how long that took. This is useful to see if you’re causing high disk load but also so you can monitor how often data is being written. Remember that while it isn’t synced to disk, you could experience data loss in the event of a crash or power outage.



The op counters – inserts, updates, deletes and queries – are fun to look at, especially if the numbers are high. But you have to be careful these are not just vanity metrics. There are some things you can use them for though.

If you have a high number of inserts and updates, i.e. writes, then you may want to look at your fsync time setting. By default this will flush to disk every 60 seconds but if you’re doing thousands of writes per second you might want to do this sooner for durability. Of course you can also ensure the write happens from within the driver by using the safe option and calling getLastError.

Queries can show whether you need to load off reads to your slaves, which can be done through the drivers, so that you’re spreading the load across your servers and only writing to the master.

Deletes can also cause concurrency problems if you’re doing a large number of them and the database keeps having to yield.

The others

We’ve missed a few sections here – globalLock and cursors are more useful to see in real time using mongostat and repl is covered by the rs.status() command. All of these are covered in different posts.

Stay tuned

This is the 3rd post in a series of 6 on MongoDB Monitoring. View the full post index and don’t forget to subscribe via RSS or Twitter to be notified of new posts and other cool stuff!