> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt # 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 [Database Profiler](https://www.mongodb.com/docs/manual/tutorial/manage-the-database-profiler.md#std-label-database-profiler) section. The database profiler writes data in the [`system.profile`](https://www.mongodb.com/docs/manual/reference/system-collections.md#mongodb-data--database-.system.profile) collection, which is a [capped collection](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-capped-collection). To view the profiler's output, use normal MongoDB queries on the [`system.profile`](https://www.mongodb.com/docs/manual/reference/system-collections.md#mongodb-data--database-.system.profile) collection. **Note:** Because the database profiler writes data to the [`system.profile`](https://www.mongodb.com/docs/manual/reference/system-collections.md#mongodb-data--database-.system.profile) collection in a database, the profiler profiles some write activity, even for databases that are otherwise read-only. [`currentOp`](https://www.mongodb.com/docs/manual/reference/command/currentop.md#mongodb-dbcommand-dbcmd.currentOp) and the database profiler report the same basic diagnostic information for CRUD operations, including the following: - [`aggregate`](https://www.mongodb.com/docs/manual/reference/command/aggregate.md#mongodb-dbcommand-dbcmd.aggregate) - [`count`](https://www.mongodb.com/docs/manual/reference/command/count.md#mongodb-dbcommand-dbcmd.count) - [`delete`](https://www.mongodb.com/docs/manual/reference/command/delete.md#mongodb-dbcommand-dbcmd.delete) - [`distinct`](https://www.mongodb.com/docs/manual/reference/command/distinct.md#mongodb-dbcommand-dbcmd.distinct) - `find` ([OP\_QUERY](https://www.mongodb.com/docs/manual/legacy-opcodes.md#std-label-wire-op-query) and [`command`)](https://www.mongodb.com/docs/manual/reference/command/find.md#mongodb-dbcommand-dbcmd.find) - [`findAndModify`](https://www.mongodb.com/docs/manual/reference/command/findandmodify.md#mongodb-dbcommand-dbcmd.findAndModify) - `getMore` ([OP\_GET\_MORE](https://www.mongodb.com/docs/manual/legacy-opcodes.md#std-label-wire-op-query) and [`command`)](https://www.mongodb.com/docs/manual/reference/command/getmore.md#mongodb-dbcommand-dbcmd.getMore) - [`insert`](https://www.mongodb.com/docs/manual/reference/command/insert.md#mongodb-dbcommand-dbcmd.insert) - [`mapReduce`](https://www.mongodb.com/docs/manual/reference/command/mapreduce.md#mongodb-dbcommand-dbcmd.mapReduce) - [`update`](https://www.mongodb.com/docs/manual/reference/command/update.md#mongodb-dbcommand-dbcmd.update) These operations are also included in the logging of slow queries. See [`slowOpThresholdMs`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-operationProfiling.slowOpThresholdMs) for more information about slow query logging. When using [Queryable Encryption](https://www.mongodb.com/docs/manual/core/queryable-encryption.md#std-label-qe-manual-feature-qe), CRUD operations against encrypted collections are omitted from the [`system.profile`](https://www.mongodb.com/docs/manual/reference/system-collections.md#mongodb-data--database-.system.profile) collection. For details, see [Redaction.](https://www.mongodb.com/docs/manual/core/queryable-encryption/reference/limitations.md#std-label-qe-redaction) It is no longer possible to perform any operation, including reads, on the [`system.profile`](https://www.mongodb.com/docs/manual/reference/system-collections.md#mongodb-data--database-.system.profile) collection from within a [transaction.](https://www.mongodb.com/docs/manual/core/transactions.md#std-label-transactions) ## Output Fields For any single operation, the documents created by the database profiler includes 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. The type of operation. The possible values are: - `command` - `count` - `distinct` - `geoNear` - `getMore` - `group` - `insert` - `mapReduce` - `query` - `remove` - `update` The [namespace](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-namespace) the operation targets. Namespaces in MongoDB take the form of the [database](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-database), followed by a dot (`.`), followed by the name of the [collection.](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-collection) A document containing the full command object associated with this operation. For example, the following output contains the command object for a [`find`](https://www.mongodb.com/docs/manual/reference/command/find.md#mongodb-dbcommand-dbcmd.find) operation on a collection named `items` in a database named `test`: ```javascript "command" : { "find" : "items", "filter" : { "sku" : 1403978 }, ... "$db" : "test" } ``` The following example output contains the command object for a [`getMore`](https://www.mongodb.com/docs/manual/reference/command/getmore.md#mongodb-dbcommand-dbcmd.getMore) operation generated by a command with cursor ID `19234103609` on a collection named `items` in a database named `test`: ```javascript "command" : { "getMore" : Long("19234103609"), "collection" : "items", "batchSize" : 10, ... "$db" : "test" }, ``` If the command document exceeds 50 kilobytes, the document has the following form: ```javascript "command" : { "$truncated": , "comment": } ``` The `$truncated` field contains a string summary of the document excluding the document's `comment` 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. A comment may be attached to any [database command.](https://www.mongodb.com/docs/manual/reference/command.md#std-label-database-commands) For `"getmore"` operations which retrieve the next batch of results from a cursor, the `originatingCommand` field contains the full command object (e.g. `find` or `aggregate`) which originally created that cursor. The ID of the cursor accessed by a `query` and `getmore` operations. The number of [index](https://www.mongodb.com/docs/manual/indexes.md#std-label-indexes) keys that MongoDB scanned in order to carry out the operation. In general, if [`keysExamined`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.keysExamined) is much higher than [`nreturned`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.nreturned), the database is scanning many index keys to find the result documents. Consider creating or adjusting indexes to improve query performance.. `keysExamined` is available for the following commands and operations: - [`aggregate`](https://www.mongodb.com/docs/manual/reference/command/aggregate.md#mongodb-dbcommand-dbcmd.aggregate) - `find` ([OP\_QUERY](https://www.mongodb.com/docs/manual/legacy-opcodes.md#std-label-wire-op-query) and [`command`)](https://www.mongodb.com/docs/manual/reference/command/find.md#mongodb-dbcommand-dbcmd.find) - [`findAndModify`](https://www.mongodb.com/docs/manual/reference/command/findandmodify.md#mongodb-dbcommand-dbcmd.findAndModify) - [`count`](https://www.mongodb.com/docs/manual/reference/command/count.md#mongodb-dbcommand-dbcmd.count) - [`distinct`](https://www.mongodb.com/docs/manual/reference/command/distinct.md#mongodb-dbcommand-dbcmd.distinct) - `getMore` ([OP\_GET\_MORE](https://www.mongodb.com/docs/manual/legacy-opcodes.md#std-label-wire-op-query) and [`command`)](https://www.mongodb.com/docs/manual/reference/command/getmore.md#mongodb-dbcommand-dbcmd.getMore) - [`mapReduce`](https://www.mongodb.com/docs/manual/reference/command/mapreduce.md#mongodb-dbcommand-dbcmd.mapReduce) - [`delete`](https://www.mongodb.com/docs/manual/reference/command/delete.md#mongodb-dbcommand-dbcmd.delete) - [`update`](https://www.mongodb.com/docs/manual/reference/command/update.md#mongodb-dbcommand-dbcmd.update) The number of documents in the collection that MongoDB scanned in order to carry out the operation. `docsExamined` is available for the following commands and operations: - [`aggregate`](https://www.mongodb.com/docs/manual/reference/command/aggregate.md#mongodb-dbcommand-dbcmd.aggregate) - `find` ([OP\_QUERY](https://www.mongodb.com/docs/manual/legacy-opcodes.md#std-label-wire-op-query) and [`command`)](https://www.mongodb.com/docs/manual/reference/command/find.md#mongodb-dbcommand-dbcmd.find) - [`findAndModify`](https://www.mongodb.com/docs/manual/reference/command/findandmodify.md#mongodb-dbcommand-dbcmd.findAndModify) - [`count`](https://www.mongodb.com/docs/manual/reference/command/count.md#mongodb-dbcommand-dbcmd.count) - [`distinct`](https://www.mongodb.com/docs/manual/reference/command/distinct.md#mongodb-dbcommand-dbcmd.distinct) - `getMore` ([OP\_GET\_MORE](https://www.mongodb.com/docs/manual/legacy-opcodes.md#std-label-wire-op-query) and [`command`)](https://www.mongodb.com/docs/manual/reference/command/getmore.md#mongodb-dbcommand-dbcmd.getMore) - [`mapReduce`](https://www.mongodb.com/docs/manual/reference/command/mapreduce.md#mongodb-dbcommand-dbcmd.mapReduce) - [`delete`](https://www.mongodb.com/docs/manual/reference/command/delete.md#mongodb-dbcommand-dbcmd.delete) - [`update`](https://www.mongodb.com/docs/manual/reference/command/update.md#mongodb-dbcommand-dbcmd.update) **Note:** For write operations, `keysExamined` and `docsExamined` include reads performed during [write conflict](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-write-conflict) retries. If an update encounters write conflicts and retries, MongoDB re-reads the index keys and documents on each attempt. As a result, these values can exceed the number of documents matched or modified by the operation. **New in version 8.3** Number of bytes of tracked memory in use by the current query operation. **New in version 8.3** Maximum number of bytes of tracked memory in use by the current query operation. [`hasSortStage`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.hasSortStage) 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`. `hasSortStage` is available for the following commands and operations: - `find` ([OP\_QUERY](https://www.mongodb.com/docs/manual/legacy-opcodes.md#std-label-wire-op-query) and [`command`)](https://www.mongodb.com/docs/manual/reference/command/find.md#mongodb-dbcommand-dbcmd.find) - `getMore` ([OP\_GET\_MORE](https://www.mongodb.com/docs/manual/legacy-opcodes.md#std-label-wire-op-query) and [`command`)](https://www.mongodb.com/docs/manual/reference/command/getmore.md#mongodb-dbcommand-dbcmd.getMore) - [`findAndModify`](https://www.mongodb.com/docs/manual/reference/command/findandmodify.md#mongodb-dbcommand-dbcmd.findAndModify) - [`mapReduce`](https://www.mongodb.com/docs/manual/reference/command/mapreduce.md#mongodb-dbcommand-dbcmd.mapReduce) - [`aggregate`](https://www.mongodb.com/docs/manual/reference/command/aggregate.md#mongodb-dbcommand-dbcmd.aggregate) A boolean that indicates whether any aggregation stage wrote data to temporary files due to [memory restrictions.](https://www.mongodb.com/docs/manual/core/aggregation-pipeline-limits.md#std-label-agg-memory-restrictions) Only appears if `usedDisk` is true. The number of documents deleted by the operation. The number of documents inserted by the operation. The number of documents that match the query condition for the update operation. 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. 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`. A boolean that indicates whether the query system evicted a [cached plan](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-plans-query-optimization) and re-evaluated all candidate plans. Only present when value is `true`. A string that indicates the specific reason a [cached plan](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-plans-query-optimization) was evicted. Only present when value for `replanned` is `true`. The number of index keys inserted for a given write operation. 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.](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-write-conflict) 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.](https://www.mongodb.com/docs/manual/faq/concurrency.md#std-label-faq-concurrency-yielding) Starting in MongoDB 8.0, the existing `queryHash` field is duplicated in a new field named `planCacheShapeHash`. If you're using an earlier MongoDB version, you'll only see the `queryHash` field. Future MongoDB versions will remove the deprecated `queryHash` field, and you'll need to use the `planCacheShapeHash` field instead. **New in version 8.0** `queryShapeHash` is a hexadecimal string with the hash of a [query shape](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-query-shape). For details, see [Query Shapes.](https://www.mongodb.com/docs/manual/core/query-shapes.md#std-label-query-shapes) A hexadecimal string that represents a hash of the [plan cache query shape](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-plan-cache-query-shape) and is dependent only on the plan cache query shape. `planCacheShapeHash` can help identify slow queries, including the query filter of write operations, with the same plan cache query shape. **Note:** As with any hash function, two different plan cache query shapes may result in the same hash value. However, the occurrence of hash collisions between different plan cache query shapes is unlikely. For more information about `planCacheShapeHash` and `planCacheKey`, see [planCacheShapeHash and planCacheKey.](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-hash-plan-cache-key) Starting in MongoDB 8.0, the existing `queryHash` field is duplicated in a new field named `planCacheShapeHash`. If you're using an earlier MongoDB version, you'll only see the `queryHash` field. Future MongoDB versions will remove the deprecated `queryHash` field, and you'll need to use the `planCacheShapeHash` field instead. A hash of the key for the plan cache entry associated with the query. Unlike [`planCacheShapeHash`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.planCacheShapeHash), [`planCacheKey`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.planCacheKey) is a function of both the plan cache query shape and the currently available indexes for that shape. Specifically, if indexes that can support the query shape are added or dropped, the `planCacheKey` value may change but `planCacheShapeHash` would not. For more information about `planCacheShapeHash` and `planCacheKey`, see [planCacheShapeHash and planCacheKey.](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-hash-plan-cache-key) Starting in MongoDB 8.0, the existing `queryHash` field is duplicated in a new field named `planCacheShapeHash`. If you're using an earlier MongoDB version, you'll only see the `queryHash` field. Future MongoDB versions will remove the deprecated `queryHash` field, and you'll need to use the `planCacheShapeHash` field instead. The [query framework](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-query-framework) used to process an operation. The [`system.profile.locks`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.locks) provides information for various [lock types and lock modes](https://www.mongodb.com/docs/manual/faq/concurrency.md#std-label-faq-concurrency-locking) held during the operation. The possible lock types are: | Lock Type | Description | | --- | --- | | `ParallelBatchWriterMode` | Represents a lock for parallel batch writer mode. In earlier versions, PBWM information was reported as part of the `Global` lock information. | | `ReplicationStateTransition` | Represents lock taken for [replica set member state](https://www.mongodb.com/docs/manual/reference/replica-states.md) transitions. | | `Global` | Represents global lock. | | `Database` | Represents database lock. | | `Collection` | Represents collection lock. | | `Mutex` | Represents mutex. | | `Metadata` | Represents metadata lock. | | `DDLDatabase` | Represents a [DDL](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-DDL--Data-Definition-Language-) database lock. **New in version 7.1** | | `DDLCollection` | Represents a [DDL](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-DDL--Data-Definition-Language-) collection lock. **New in version 7.1** | | `oplog` | Represents lock on the [oplog.](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-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: Number of times the operation acquired the lock in the specified mode. Number of times the operation had to wait for the [`acquireCount`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.locks.acquireCount) lock acquisitions because the locks were held in a conflicting mode. [`acquireWaitCount`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.locks.acquireWaitCount) is less than or equal to [`acquireCount`.](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.locks.acquireCount) Cumulative time in microseconds that the operation had to wait to acquire the locks. [`timeAcquiringMicros`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.locks.timeAcquiringMicros) divided by [`acquireWaitCount`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.locks.acquireWaitCount) gives an approximate average wait time for the particular lock mode. 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?.](https://www.mongodb.com/docs/manual/faq/concurrency.md#std-label-faq-concurrency-locking) **New in version 5.0.0** The number of times the user cache is accessed for each operation. These metrics are only displayed when an operation has accessed the user cache at least once. These metrics are only available when [slow operation logging](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-slow-ops) or database profiling is enabled. [`system.profile.authorization`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.authorization) is not included in [`db.currentOp()`](https://www.mongodb.com/docs/manual/reference/method/db.currentop.md#mongodb-method-db.currentOp) output. The number of times the operation tried to access the user cache. The number of times the operation retrieved user data from the user cache. The total time the operation spent waiting for user cache responses. The [`system.profile.storage`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-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. 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. Time in microseconds that the operation had to spend to read from the disk. 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. Time in microseconds that the operation had to spend to write to the disk. Time in microseconds that the operation had to wait for space in the cache. Time in microseconds that the operation (if modifying the schema) had to wait to acquire a schema lock. Time in microseconds that the operation had to wait to acquire the a lock on the needed data handles. The number of documents returned by the operation. The length in bytes of the operation's result document. A large [`responseLength`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.responseLength) can affect performance. To limit the size of the result document for a query operation, you can use any of the following: - [Projections](https://www.mongodb.com/docs/manual/tutorial/project-fields-from-query-results.md#std-label-read-operations-projection) - [`The limit() method`](https://www.mongodb.com/docs/manual/reference/method/cursor.limit.md#mongodb-method-cursor.limit) - [`The batchSize() method`](https://www.mongodb.com/docs/manual/reference/method/cursor.batchsize.md#mongodb-method-cursor.batchSize) **Note:** When MongoDB writes query profile information to the log, the [`responseLength`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.responseLength) value is in a field named `reslen`. **New in version 6.3** The total CPU time spent by a query operation in nanoseconds. This field is only available on Linux systems. The [MongoDB Wire Protocol](https://www.mongodb.com/docs/manual/reference/mongodb-wire-protocol.md#std-label-mongodb-wire-protocol) request message format. The time in milliseconds from the perspective of the [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) from the beginning of the operation to the end of the operation. **New in version 6.2** The time, in microseconds, that the `find` or `aggregate` command spent in [query planning.](https://www.mongodb.com/docs/manual/core/query-plans.md#std-label-query-plans-query-optimization) **Note:** Before MongoDB 7.0.22, 8.0.5, and 8.1.0, `planningTimeMicros` might include non-planning work, such as a sharding metadata refresh. `planningTimeMicros` might also include cached-plan trial-run time, even if the query doesn't replan. Don't rely on this field alone to evaluate query-planning performance. Review the total operation duration, [`keysExamined`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.keysExamined), [`docsExamined`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.docsExamined), and relevant sharding or lock-wait metrics. For more information, see [SERVER-92476](https://jira.mongodb.org/browse/SERVER-92476) and [SERVER-106502](https://jira.mongodb.org/browse/SERVER-106502) in JIRA. A summary of the execution plan. A document that contains the execution statistics of the query operation. For other operations, the value is an empty document. The [`system.profile.execStats`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-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`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.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 input stages of the current stage. The timestamp of the operation. The IP address or hostname of the client connection where the operation originates. The identifier of the client application which ran the operation. Use the [`appName`](https://www.mongodb.com/docs/manual/reference/connection-string-options.md#mongodb-urioption-urioption.appName) connection string option to set a custom value for the `appName` field. An array of authenticated user information (user name and database) for the session. See also [Users in Self-Managed Deployments.](https://www.mongodb.com/docs/manual/core/security-users.md#std-label-users) 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. ## Example `system.profile` Document The following examples present sample documents found in the [`system.profile`](https://www.mongodb.com/docs/manual/reference/system-collections.md#mongodb-data--database-.system.profile) collection for operations on a standalone: ### Find Operation The following document in the [`system.profile`](https://www.mongodb.com/docs/manual/reference/system-collections.md#mongodb-data--database-.system.profile) collection shows metrics for a sample query operation on the `test.report` collection: ```javascript { "op" : "query", "ns" : "test.report", "command" : { "find" : "report", "filter" : { "a" : { "$lte" : 500 } }, "lsid" : { "id" : UUID("5ccd5b81-b023-41f3-8959-bf99ed696ce9") }, "$db" : "test" }, "cursorid" : 33629063128, "keysExamined" : 101, "docsExamined" : 101, "inUseTrackedMemBytes" : Long(368), "peakTrackedMemBytes" : Long(795), "fromMultiPlanner" : true, "numYield" : 2, "nreturned" : 101, "planCacheShapeHash" : "811451DD", "planCacheKey" : "759981BA", "queryFramework" : "classic", "locks" : { "Global" : { "acquireCount" : { "r" : Long(3), "w" : Long(3) } }, "Database" : { "acquireCount" : { "r" : Long(3) }, "acquireWaitCount" : { "r" : Long(1) }, "timeAcquiringMicros" : { "r" : Long(69130694) } }, "Collection" : { "acquireCount" : { "r" : Long(3) } } }, "storage" : { "data" : { "bytesRead" : Long(14736), "timeReadingMicros" : Long(17) } }, "responseLength" : 1305014, "protocol" : "op_msg", "millis" : 69132, "planningTimeMicros" : 129, "planSummary" : "IXSCAN { a: 1, _id: -1 }", "execStats" : { "stage" : "FETCH", "nReturned" : 101, "executionTimeMillisEstimate" : 0, "works" : 101, "advanced" : 101, "needTime" : 0, "needYield" : 0, "saveState" : 3, "restoreState" : 2, "isEOF" : 0, "docsExamined" : 101, "alreadyHasObj" : 0, "inputStage" : { ... } }, "ts" : ISODate("2019-01-14T16:57:33.450Z"), "client" : "127.0.0.1", "appName" : "MongoDB Shell", "allUsers" : [ { "user" : "someuser", "db" : "admin" } ], "user" : "someuser@admin" } ```