Database Profiler Output¶

On this page

Example system.profile Document
Output Reference

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.

Note

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 insert operation:

copy

{
    "op" : "insert",
    "ns" : "test.orders",
    "query" : {
       "_id" : 1,
       "cust_id" : "A123",
       "amount" : 500,
       "status" : "A"
    },
    "ninserted" : 1,
    "keyUpdates" : 0,
    "writeConflicts" : 0,
    "numYield" : 0,
    "locks" : {
          "Global" : {
             "acquireCount" : {
                "w" : NumberLong(1)
             }
          },
          "MMAPV1Journal" : {
             "acquireCount" : {
                "w" : NumberLong(2)
             }
          },
          "Database" : {
             "acquireCount" : {
                "w" : NumberLong(1)
             }
          },
          "Collection" : {
             "acquireCount" : {
                "W" : NumberLong(1)
             }
          }
       },
    ,
    "millis" : 0,
    "execStats" : {
    },
    "ts" : ISODate("2012-12-10T19:31:28.977Z"),
    "client" : "127.0.0.1",
    "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.

Note

For the output specific to the version of your MongoDB, refer to the appropriate version of the MongoDB Manual.

system.profile.op¶

The type of operation. The possible values are:

insert
query
update
remove
getmore
command

system.profile.ns¶: 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.

system.profile.query¶: The query document used, or for an insert operation, the inserted document. If the document exceeds 50 kilobytes, the value is a string summary of the object. If the string summary exceeds 50 kilobytes, the string summary is truncated, denoted with an ellipsis (...) at the end of the string.

Changed in version 3.0.4: 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.

system.profile.command¶: The command operation. If the command document exceeds 50 kilobytes, the value is a string summary of the object. If the string summary exceeds 50 kilobytes, the string summary is truncated, denoted with an ellipsis (...) at the end of the string.

system.profile.updateobj¶: The <update> document passed in during an update operation. If the document exceeds 50 kilobytes, the value is a string summary of the object. If the string summary exceeds 50 kilobytes, the string summary is truncated, denoted with an ellipsis (...) at the end of the string.

system.profile.cursorid¶: The ID of the cursor accessed by a query and getmore operations.

system.profile.ntoreturn¶

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.

system.profile.ntoskip¶: The number of documents the skip() method specified to skip.

system.profile.nscanned¶

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.

system.profile.nscannedObjects¶: The number of documents that MongoDB scans from the collection in order to carry out the operation.

system.profile.moved¶: Changed in version 3.0.0: Only appears when using the MMAPv1 storage engine.

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.

system.profile.nmoved¶: Changed in version 3.0.0: Only appears when using the MMAPv1 storage engine.

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.

system.profile.scanAndOrder¶: scanAndOrder is a boolean that is true when a query cannot use the ordering in the index to return the requested sorted results; i.e. MongoDB must sort the documents after it receives the documents from a cursor. The field only appears when the value is true.

system.profile.ndeleted¶: The number of documents deleted by the operation.

system.profile.ninserted¶: The number of documents inserted by the operation.

system.profile.nMatched¶: New in version 2.6.

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

system.profile.nModified¶: New in version 2.6.

The number of documents modified by the update operation.

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

system.profile.keyUpdates¶: 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.

system.profile.writeConflicts¶: New in version 3.0.0.

The number of conflicts encountered during the write operation; e.g. an update operation attempts to modify the same document as another update operation. See also write conflict.

system.profile.numYield¶: 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.

system.profile.locks¶

New in version 3.0.0: locks replaces the lockStats field.

The system.profile.locks provides information for various lock types and lock modes held during the operation.

The possible lock types are:

Global represents global lock.
MMAPV1Journal represents MMAPv1 storage engine specific lock to synchronize journal writes; for non-MMAPv1 storage engines, the mode for MMAPV1Journal is empty.
Database represents database lock.
Collection represents collection lock.
Metadata represents metadata lock.
oplog represents lock on the oplog.

The possible locking modes for the lock types are as follows:

R represents Shared (S) lock.
W represents Exclusive (X) lock.
r represents Intent Shared (IS) lock.
w represents Intent Exclusive (IX) lock.

The returned lock information for the various lock types include:

system.profile.locks.acquireCount¶: Number of times the operation acquired the lock in the specified mode.

system.profile.locks.acquireWaitCount¶: Number of times the operation had to wait for the acquireCount lock acquisitions because the locks were held in a conflicting mode. acquireWaitCount is less than or equal to acquireCount.

system.profile.locks.timeAcquiringMicros¶

Cumulative time in microseconds that the operation had to wait to acquire the locks.

timeAcquiringMicros divided by acquireWaitCount gives an approximate average wait time for the particular lock mode.

system.profile.locks.deadlockCount¶: Number of times the operation encountered deadlocks while waiting for lock acquisitions.

For more information on lock modes, see What type of locking does MongoDB use?.

system.profile.nreturned¶: The number of documents returned by the operation.

system.profile.responseLength¶

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:

Note

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

system.profile.millis¶: The time in milliseconds from the perspective of the mongod from the beginning of the operation to the end of the operation.

system.profile.execStats¶

Changed in version 3.0.

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 statistics as a tree; each node provides the statistics for the operation executed during that stage of the query operation.

Note

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

system.profile.execStats.stage¶

New in version 3.0: stage replaces the type field.

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

system.profile.execStats.inputStages¶: New in version 3.0: inputStages replaces the children field.

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

system.profile.ts¶: The timestamp of the operation.

system.profile.client¶

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

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

system.profile.allUsers¶: An array of authenticated user information (user name and database) for the session. See also Users.

system.profile.user¶: 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.

← System Collections Server Status Output →

Database Profiler Output¶

Example system.profile Document¶

Output Reference¶

Example `system.profile` Document¶