The most common use for db.currentOp() is looking for slow operations. You can use the filtering technique described in the previous section to find all queries that take longer than a certain amount of time, which may suggest a missing index or improper field filtering.

Sometimes people will find that unexpected queries are running, generally because there’s an app server running an old or buggy version of software. The "client" field can help track down where unexpected operations are coming from.

If you find an operation that you want to stop, you can kill it by passing db.killOp() its "opid":

> db.killOp(123)

Not all operations can be killed. In general, operations can only be killed when they yield, so updates, finds, and removes can all be killed. Operations holding or waiting for a lock usually cannot be killed.

Once you have sent a “kill” message to an operation, it will have a "killed" field in the db.currentOp output. However, it won’t actually be dead until it disappears from list of current opertations.

If you look for slow operations, you may see some long-running internal operations listed. There are several long-running requests MongoDB may have running, depending on your setup. The most common are the replication thread (which will continue fetching more operations from the sync source for as long as possible) and the writeback listener for sharding. Any long-running query on local.oplog.rs can be ignored as well as any writebacklistener commands.

If you kill either of these operations, MongoDB will just restart them. However, you generally should not do that. Killing the replication thread will briefly halt replication and killing the writeback listener may cause mongos to miss legitimate write errors.

There is an odd, MongoDB-specific issue that you may run into, particularly if you’re bulk-loading data into a collection. Suppose you have a job that is firing thousands of update operations at MongoDB and MongoDB is grinding to a halt. You quickly stop the job and kill off all the updates that are currently occurring. However, you continue to see new updates appearing as soon as you kill the old ones, even though the job is no longer running!

If you are loading data using unacknowledged writes, your application will fire writes at MongoDB, potentially faster than MongoDB can process them. If MongoDB gets backed up, these writes will pile up in the operating system’s socket buffer. When you kill the writes MongoDB is working on, this allows MongoDB to start processing the writes in the buffer. Even if you stop the client sending the writes, any writes that made it into the buffer will get processed by MongoDB, since they’ve already been “received” (just not processed).

The best way to prevent these phantom writes is to do acknowledged writes: make each write wait until the previous write is complete, not just until the previous write is sitting in a buffer on the database server.

The easiest way to get the size of a document is to use the shell’s Object.bsonsize() function. Pass in any document to get the size it would be when stored in MongoDB.

For example, you can see that storing _ids as ObjectIds is more efficient than storing them as strings:

> Object.bsonsize({_id:ObjectId()})
22
> // ""+ObjectId() converts the ObjectId to a string
> Object.bsonsize({_id:""+ObjectId()})
39

More practically, you can pass in documents directly from your collections:

> Object.bsonsize(db.users.findOne())

This shows you exactly how many bytes a document is taking up on disk. However, this does not count padding or indexes, which can often be significant factors in the size of a collection.

For seeing information about a whole collection, there is a stats function:

> db.boards.stats()
{
    "ns" : "brains.boards",
    "count" : 12,
    "size" : 32292,
    "avgObjSize" : 2691,
    "storageSize" : 270336,
    "numExtents" : 3,
    "nindexes" : 2,
    "lastExtentSize" : 212992,
    "paddingFactor" : 1.0099999999999825,
    "flags" : 1,
    "totalIndexSize" : 16352,
    "indexSizes" : {
        "_id_" : 8176,
        "username_1_slug_1" : 8176
    },
    "ok" : 1
}

stats starts with the namespace ("brains.boards") and then the count of all documents in the collection. The next couple of fields have to do with the size of the collection. "size" is what you’d get if you called Object.bsonsize() on each element in the collection and added up all the sizes: it’s the actual number of bytes the document in the collection are taking up. Equivalently, if you take the "avgObjSize" and multiply it by "count", you’ll get "size".

As mentioned above, a total count of the documents’ bytes leaves out some important space a collection uses: the padding around each document and the indexes. "storageSize" not only includes those, but also empty space that has been set aside for the collection but not yet used. Collections always have empty space at the “end” so that new documents can be added quickly.

"nindexes" is the number of indexes on the collection. An index is not counted in "nindexes" until it finishes being built and cannot be used until it appears in this list. Each index is currently one “bucket” (8 KB), since the collection is so small. In general, indexes will be a lot larger than the amount of data they store, as there is a lot of free space to optimize adding new entries. You can minimize this free space by having right-balanced indexes (as described in Introduction to Compound Indexes). Indexes that are randomly distributed will generally be approximately 50% free space, whereas ascending-order indexes will be 10% free space.

As your collections get bigger, it may become difficult to read stats() output with sizes in the billions of bytes or beyond. Thus, you can pass in a scaling factor: 1024 for kilobytes, 1024*1024 for megabytes, and so on. For example, this would get the collection stats in terabytes:

> db.big.stats(1024*1024*1024*1024)

Databases have a stats function that’s similar to collections’:

> db.stats()
{
    "db" : "brains",
    "collections" : 11,
    "objects" : 1109,
    "avgObjSize" : 299.79440937781783,
    "dataSize" : 332472,
    "storageSize" : 1654784,
    "numExtents" : 15,
    "indexes" : 11,
    "indexSize" : 114464,
    "fileSize" : 201326592,
    "nsSizeMB" : 16,
    "ok" : 1
}

First, we have the name of the database and the number of collections it contains. "objects" is the total count of documents across all collections in this database.

The bulk of the document contains information about the size of your data. "fileSize" should always be the largest: that is the total amount allocated to the database files. This number should be equivalent to adding the sizes of all of the brains.* files in your data directory.

The next largest field is generally going to be "storageSize", which is the total amount of space the database is using. This doesn’t match "fileSize" because "fileSize" includes preallocated files. For example, if you have brains.0, brains.1, and brains.2 in your data directory, brains.2 will be filled with zeros. As soon as anything is written to brains.2, brains.3 will be allocated. You should always have an empty (full of zeros) file for each database: as soon as it’s written to, the next file will be preallocated. Thus, this empty file (plus anything not being used yet in the previous files) is the difference between "fileSize" and "storageSize".

"dataSize" is the amount of space the data in this database is taking up. Note that this does not include space on the free list, but it does include documents’ padding. Thus, the difference between this and the "storageSize" should be the size of documents deleted.

db.stats() can take a scale argument the same way that the collections’ stats() function can.

If you call db.stats() on a nonexistent database, the "nsSizeMB" will be 0. This is the size of the .ns file, which is essentially a database’s table of contents. Any database that exists needs a .ns file

Keep in mind that listing databases on a system with a high lock percent can be very slow and block other operations. Avoid doing it, if possible.