MongoDB Monitoring: Watch your storage

By David Mytton,
CEO & Founder of Server Density.

Published on the 21st December, 2010.

Man carrying a cart of boxes in Osaka, Japan

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 2nd 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.

Watch your storage

It sounds obvious but our statistics show that people run out disk space suddenly, even though there is a predictable increase over time. Remember that MongoDB pre-allocates files before the space is used.

The database files are stored in your --dbpath and are allocated in advance of being used in order to prevent file system fragmentation. The first file for a database is .0, then .1, etc. .0 will be 64MB, .1 128MB, etc., up to 2GB. Once the files reach 2GB in size, each successive file is also 2GB.

This means you will see your disk usage increasing by 2GB increments (after the first few files) even though you might not yet be using (some or all of) the space.

Sharding maxSize

When adding a new shard you can specify the maximum amount of data you want to store on that shard by including a maxSize in your sharding config:

db.runCommand( { addshard : "set1/rs1a:27018,rs1b:27018", maxSize: 409600, name : "shard1" } ); // 400GB maxsize

This isn’t a hard limit and is instead used as a guide (source). MongoDB will try to keep the data balanced across all your shards so that it meets this setting, but it may not. It doesn’t currently look at actual disk levels and assumes available capacity is the same across all nodes. As such, it’s advisable that you set this to around 70% of the total available disk space. This will get more intelligent in future releases.


Logging is verbose by default, so you’ll want to use the --quiet option to ensure only important things are output. And assuming you’re logging to a log file, you will want to periodically rotate it via the MongoDB console so that it doesn’t get too big:


You can also do a killall SIGUSR1 on all your mongod processes from the shell which will cause a log rotation (because of the SIGUSR1 flag). This is useful if you want to script log rotation or put it into a cron job.

Stay tuned

This is the 2nd 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!

Articles you care about. Delivered.

Help us speak your language. What is your primary tech stack?

Maybe another time