- Administration >
- MongoDB Performance >
- Database Profiler >
- Database Profiler Output
Database Profiler Output¶
On this page
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 Database Profiler 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.
Changed in version 3.4.
currentOp
and the
database profiler report the same
basic diagnostic information for all CRUD operations, including the
following:
aggregate
count
delete
distinct
find
(OP_QUERY andcommand
)findAndModify
geoNear
getMore
(OP_GET_MORE andcommand
)group
insert
mapReduce
update
These operations are also included in the logging of
slow queries (see slowOpThresholdMs
for
more information about slow query logging).
Example system.profile
Document¶
The following presents some sample documents found in the
system.profile
collection for
operations on a standalone:
- Find Operation
- Update Operation
The following document in the system.profile
reflects a find operation:
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.
In MongoDB 4.0.9+, the profiler entries and diagnostic log
messages include
storage
information for slow operations.
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:
command
count
distinct
geoNear
getMore
group
insert
mapReduce
query
remove
update
-
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.
command
¶ Changed in version 3.6.
A document containing the full command object associated with this operation. If the command document exceeds 50 kilobytes, the document has the following form:
The
$truncated
field contains a string summary of the document excluding the document’scomment
field if present. If the summary still exceeds 50 kilobytes then it is further truncated, denoted by an ellipsis (…) at the end of the string.The
comment
field is present if a comment was passed to the operation.The following example output contains the command object for a
find
operation on a collection nameditems
in a database namedtest
:The following example output contains the command object for a
getMore
operation generated by a command with cursor id80336119321
on a collection nameditems
in a database namedtest
:
-
system.profile.
originatingCommand
¶ Changed in version 3.6: For
"getmore"
operations which retrieve the next batch of results from a cursor, theoriginatingCommand
field contains the full command object (e.g.find
oraggregate
) which originally created that cursor.
-
system.profile.
cursorid
¶ The ID of the cursor accessed by a
query
andgetmore
operations.
-
system.profile.
keysExamined
¶ Changed in version 3.2.0.
Renamed from
system.profile.nscanned
. The number of index keys that MongoDB scanned in order to carry out the operation.In general, if
keysExamined
is much higher thannreturned
, the database is scanning many index keys to find the result documents. Consider creating or adjusting indexes to improve query performance..Changed in version 3.4.
keysExamined
is available for the following commands and operations:
-
system.profile.
docsExamined
¶ Changed in version 3.2.0: Renamed from
system.profile.nscannedObjects
.The number of documents in the collection that MongoDB scanned in order to carry out the operation.
Changed in version 3.4.
docsExamined
is available for the following commands and operations:
-
system.profile.
moved
¶ Removed in 3.4.
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.
hasSortStage
¶ Changed in version 3.2.0: Renamed from
system.profile.scanAndOrder
.hasSortStage
is a boolean that istrue
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 istrue
.Changed in version 3.4.
hasSortStage
is available for the following commands and operations:find
(OP_QUERY andcommand
)getMore
(OP_GET_MORE andcommand
)findAndModify
mapReduce
aggregate
-
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 ifupsert
is true.
-
system.profile.
fastmodinsert
¶ Deprecated since version 3.4.
Records the number of update operations that match all of the following criteria:
- Are upserts (that result in an insert)
- Do not use a modifier operation such as
$set
-
system.profile.
fromMultiPlanner
¶ New in version 3.2.5.
A boolean that indicates whether the query planner evaluated multiple plans before choosing the winning execution plan for the query.
Only present when value is
true
.
-
system.profile.
replanned
¶ New in version 3.2.5.
A boolean that indicates whether the query system evicted a cached plan and re-evaluated all candidate plans.
Only present when value is
true
.
-
system.profile.
replanReason
¶ New in version 4.0.19.
A string that indicates the specific reason a cached plan was evicted.
Only present when value for
replanned
istrue
.
-
system.profile.
keysInserted
¶ The number of index keys inserted for a given write operation.
-
system.profile.
keysDeleted
¶ Removed in 3.4.
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 anotherupdate
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 thelockStats
field.The
system.profile.locks
provides information for various lock types and lock modes held during the operation.The possible lock types are:
Lock Type Description 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:
Lock Mode Description 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 toacquireCount
.
-
system.profile.locks.
timeAcquiringMicros
¶ Cumulative time in microseconds that the operation had to wait to acquire the locks.
timeAcquiringMicros
divided byacquireWaitCount
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.
storage
¶ New in version 4.0.9.
The
system.profile.storage
information provides metrics on the storage engine data and wait time for the operation.Specific storage metrics are returned only if the values are greater than zero.
-
system.profile.storage.data.
bytesRead
¶ New in version 4.0.9.
Number of bytes read by the operation from the disk to the cache.
Data read from disk into the cache includes everything needed to execute the query. If the data is already in the cache, then the number of bytes read from disk could be
0
.The number of bytes read from disk includes more than the queried documents:
- WiredTiger reads in units of pages and a page may contain one or
several documents. If a document is in a page, all documents in that
page are read into the cache and included in the
bytesRead
value. - If the cache requires page management (such as eviction or rereads),
the
bytesRead
value includes data read from disk in these operations. - If the index is not in the cache or the index in the cache is stale, WiredTiger reads several internal and leaf pages from disk to reconstruct the index in cache.
- WiredTiger reads in units of pages and a page may contain one or
several documents. If a document is in a page, all documents in that
page are read into the cache and included in the
-
system.profile.storage.data.
timeReadingMicros
¶ New in version 4.0.9.
Time in microseconds that the operation had to spend to read from the disk.
-
system.profile.storage.data.
bytesWritten
¶ New in version 4.0.9.
Number of bytes written by the operation from the cache to the disk.
WiredTiger typically doesn’t require the query to write to disk. Data modified by the query is written to an in-memory cache that WiredTiger flushes to disk as part an eviction or checkpoint operation. In such cases,
bytesWritten
shows as 0.If the thread running the query requires forced page management (such as eviction), WiredTiger writes the page contents to disk. This flush likely includes data unrelated to changes made by the query itself, which can cause
bytesWritten
to show a higher value than expected.
-
system.profile.storage.data.
timeWritingMicros
¶ New in version 4.0.9.
Time in microseconds that the operation had to spend to write to the disk.
-
system.profile.storage.timeWaitingMicros.
cache
¶ New in version 4.0.9.
Time in microseconds that the operation had to wait for space in the cache.
-
system.profile.storage.timeWaitingMicros.
schemaLock
¶ New in version 4.0.9.
Time in microseconds that the operation (if modifying the schema) had to wait to acquire a schema lock.
-
system.profile.storage.timeWaitingMicros.
handleLock
¶ New in version 4.0.9.
Time in microseconds that the operation had to wait to acquire the a lock on the needed data handles.
-
-
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 namedreslen
.
-
system.profile.
protocol
¶ The MongoDB Wire Protocol request message format.
-
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.
planSummary
¶ New in version 3.4.
A summary of the execution plan.
-
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 thetype
field.The descriptive name for the operation performed as part of the query execution; e.g.
COLLSCAN
for a collection scanIXSCAN
for scanning index keysFETCH
for retrieving documents
-
system.profile.execStats.
inputStages
¶ New in version 3.0:
inputStages
replaces thechildren
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 is0.0.0.0:0
instead of an actual client.
-
system.profile.
appName
¶ New in version 3.4.
The identifier of the client application which ran the operation. Use the
appName
connection string option to set a custom value for theappName
field.
-
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.