flushes – this shows how many times data has been flushed to disk. MongoDB only physically writes data to disk every 60 seconds (by default). This has the effect of increasing performance but can decrease durability because a hard crash inbetween flushes will result in that data not being written, and therefore lost. v1.8 solves this with the option for durability but this stat shows how often mongod is flushing data to disk.
faults – the faults column shows you the number of Linux page faults per second. This is when Mongo accesses something that is mapped to the virtual address space but not in physical memory. i.e. it results in a read from disk. High values here indicate you may not have enough RAM to store all necessary data and disk accesses may start to become the bottleneck.
locked % – shows the % of time in a global write lock. When this is happening no other queries will complete until the lock is given up, or the lock owner yields. This is indicative of a large, global operation like a remove() or dropping a collection and can result in slow performance.
% idx miss – this is like we saw in the server status output except instead of an aggregate total, you can see queries hitting (or missing) the index in real time. This is useful if you’re debugging specific queries in development or need to track down a server that is performing badly.
qr|qw – when MongoDB gets too many queries to handle in real time, it queues them up. This is represented inmongostat by the read and write queue columns. When this starts to increase you will see slowdowns in executing queries as they have to wait to run through the queue. You can alleviate this by stopping any more queries until the queue has dissipated. Queues will tend to spike if you’re doing a lot of write operations alongside other write heavy ops, such as large ranged removes.
mongostat is useful because it shows what is happening in your cluster right now. This is particularly handy to quickly find out which member of your replica sets is master right now – the final column shows this. If you start seeing slowdowns or suspect a problem with MongoDB, mongostat should be your first point of call to quickly locate where the problem is.