This version of the documentation is archived and no longer supported.

Database Profiler Output

The database profiler captures data information about read and write operations, cursor operations, and database commands. To configure the database profile and set the thresholds for capturing profile data, see the Analyze Performance of Database Operations section.

The database profiler writes data in the system.profile collection, which is a capped collection. To view the profiler’s output, use normal MongoDB queries on the system.profile collection.


Because the database profiler writes data to the system.profile collection in a database, the profiler will profile some write activity, even for databases that are otherwise read-only.

Example system.profile Document

The documents in the system.profile collection have the following form. This example document reflects an update operation:

    "op" : "update",
    "ns" : "social.users",
    "query" : {
        "name" : "j.r."
    "updateobj" : {
        "$set" : {
            "likes" : [
    "nscanned" : 1,
    "nscannedObjects" : 1,
    "moved" : true,
    "nmoved" : 1,
    "nMatched" : 1,
    "nModified" : 1,
    "keyUpdates" : 0,
    "numYield" : 0,
    "lockStats" : {
        "timeLockedMicros" : {
            "r" : NumberLong(0),
            "w" : NumberLong(258)
        "timeAcquiringMicros" : {
            "r" : NumberLong(0),
            "w" : NumberLong(7)
    "millis" : 0,
    "execStats" : {
    "ts" : ISODate("2012-12-10T19:31:28.977Z"),
    "client" : "",
    "allUsers" : [ ],
    "user" : ""

Output Reference

For any single operation, the documents created by the database profiler will include a subset of the following fields. The precise selection of fields in these documents depends on the type of operation.


The type of operation. The possible values are:

  • insert
  • query
  • update
  • remove
  • getmore
  • command

The namespace the operation targets. Namespaces in MongoDB take the form of the database, followed by a dot (.), followed by the name of the collection.


The query document used.

Changed in version 2.6.11: For "getmore" operations on cursors returned from a db.collection.find() or a db.collection.aggregate(), the query field contains respectively the query predicate or the issued aggregate command document. For details on the aggregate command document, see the aggregate reference page.


The command operation.


The <update> document passed in during an update operation.


The ID of the cursor accessed by a getmore operation.


Changed in version 2.2: In 2.0, MongoDB includes this field for query and command operations. In 2.2, this information MongoDB also includes this field for getmore operations.

The number of documents the operation specified to return. For example, the profile command would return one document (a results document) so the ntoreturn value would be 1. The limit(5) command would return five documents so the ntoreturn value would be 5.

If the ntoreturn value is 0, the command did not specify a number of documents to return, as would be the case with a simple find() command with no limit specified.


New in version 2.2.

The number of documents the skip() method specified to skip.


The number of documents that MongoDB scans in the index in order to carry out the operation.

In general, if nscanned is much higher than nreturned, the database is scanning many objects to find the target objects. Consider creating an index to improve this.


The number of documents that MongoDB scans from the collection in order to carry out the operation.


This field appears with a value of true when an update operation moved one or more documents to a new location on disk. If the operation did not result in a move, this field does not appear. Operations that result in a move take more time than in-place updates and typically occur as a result of document growth.


New in version 2.2.

The number of documents the operation moved on disk. This field appears only if the operation resulted in a move. The field’s implicit value is zero, and the field is present only when non-zero.


scanAndOrder is a boolean that is true when a query cannot use the order of documents in the index for returning sorted results: MongoDB must sort the documents after it receives the documents from a cursor.

If scanAndOrder is false, MongoDB can use the order of the documents in an index to return sorted results.


The number of documents deleted by the operation.


The number of documents inserted by the operation.


New in version 2.6.

The number of documents that match the system.profile.query condition for the update operation.


New in version 2.6.

The number of documents modified by the update operation.


A boolean that indicates the update operation’s upsert option value. Only appears if upsert is true.


New in version 2.2.

The number of index keys the update changed in the operation. Changing an index key carries a small performance cost because the database must remove the old key and inserts a new key into the B-tree index.


New in version 2.2.

The number of times the operation yielded to allow other operations to complete. Typically, operations yield when they need access to data that MongoDB has not yet fully read into memory. This allows other operations that have data in memory to complete while MongoDB reads in data for the yielding operation. For more information, see the FAQ on when operations yield.


New in version 2.2.

The time in microseconds the operation spent acquiring and holding locks. This field reports data for the following lock types:

  • R - global read lock
  • W - global write lock
  • r - database-specific read lock
  • w - database-specific write lock

The time in microseconds the operation held a specific lock. For operations that require more than one lock, like those that lock the local database to update the oplog, this value may be longer than the total length of the operation (i.e. millis.)


The time in microseconds the operation spent waiting to acquire a specific lock.


The number of documents returned by the operation.


The length in bytes of the operation’s result document. A large responseLength can affect performance. To limit the size of the result document for a query operation, you can use any of the following:


When MongoDB writes query profile information to the log, the responseLength value is in a field named reslen.


The time in milliseconds from the perspective of the mongod from the beginning of the operation to the end of the operation.


New in version 2.6.

A document that contains the execution statistics of the query operation. For other operations, the value is an empty document.

The system.profile.execStats presents the staticstics as a tree; each node provides the statistics for the operation executed during that stage of the query operation.


The following fields list for execStats is not meant to be exhaustive as the returned fields vary per stage.


The descriptive name for the operation performed as part of the query execution; e.g.

  • COLLSCAN for a collection scan
  • IXSCAN for scanning index keys
  • FETCH for retrieving documents

An array that contains statistics for the operations that are the children of the current stage.


The timestamp of the operation.


The IP address or hostname of the client connection where the operation originates.

For some operations, such as db.eval(), the client is instead of an actual client.


An array of authenticated user information (user name and database) for the session. See also Client Authentication.


The authenticated user who ran the operation. If the operation was not run by an authenticated user, this field’s value is an empty string.