数据库 Profiler输出¶

On this page

在进行 update 操作时传递的 <update> 文档。
如果 scanAndOrder 为 假 ，MongoDB可以利用建有索引的文档顺序返回已排序的结果。

数据库 Profiler 记录了关于读写操作，游标操作和数据库命令相关的数据信息。关于配置数据库profile和设置记录profile数据的阈值这部分，请参见 Database Profiler 。

数据库profiler把数据写入 system.profile 集合中，该集合是一个 capped collection 。可以用普通的MongoDB查询语句查询 system.profile 集合得到profiler的输出。

注解

因为数据库profiler将数据写入数据库的 system.profile 集合，所以profiler将会记录一些活跃的写，即使是那些只读数据库。

在 3.4 版更改.

db.currentOp() and the database profiler report the same basic diagnostic information for all CRUD operations, including the following.

aggregate
对任何单个操作来说，数据库profiler创建的文档包含下列字段的子集。依靠操作类型在这些文档中进行精确的字段筛选。
delete
distinct
find (OP_QUERY and command)
findAndModify
geoNear
getMore (OP_GET_MORE and command)
group
insert
mapReduce
update

These operations are also included in the logging of slow queries (see slowOpThresholdMs for more information about slow query logging).

在进行 `update` 操作时传递的 `<update>` 文档。¶

在2.0版本中，MongoDB的 query 和 command 操作中包含这个字段。在2.2中，这些信息仍然存在，并在 getmore 操作中包含这个字段。

{
   "op" : "query",
   "ns" : "test.c",
   "query" : {
      "find" : "c",
      "filter" : {
         "a" : 1
      }
   },
   "keysExamined" : 2,
   "docsExamined" : 2,
   "cursorExhausted" : true,
   "keysInserted" : 0,
   "keysDeleted" : 0,
   "writeConflicts" : 0,
   "numYield" : 0,
   "locks" : {
      "Global" : {
         "acquireCount" : {
            "r" : NumberLong(2)
         }
      },
      "Database" : {
         "acquireCount" : {
            "r" : NumberLong(1)
         }
      },
      "Collection" : {
         "acquireCount" : {
            "r" : NumberLong(1)
         }
      }
   },
   "nreturned" : 2,
   "responseLength" : 108,
   "millis" : 0,
   "execStats" : {
      "stage" : "FETCH",
      "nReturned" : 2,
      "executionTimeMillisEstimate" : 0,
      "works" : 3,
      "advanced" : 2,
      "needTime" : 0,
      "needYield" : 0,
      "saveState" : 0,
      "restoreState" : 0,
      "isEOF" : 1,
      "invalidates" : 0,
      "docsExamined" : 2,
      "alreadyHasObj" : 0,
      "inputStage" : {
         "stage" : "IXSCAN",
         "nReturned" : 2,
         "executionTimeMillisEstimate" : 0,
         "works" : 3,
         "advanced" : 2,
         "needTime" : 0,
         "needYield" : 0,
         "saveState" : 0,
         "restoreState" : 0,
         "isEOF" : 1,
         "invalidates" : 0,
         "keyPattern" : {
            "a" : 1
         },
         "indexName" : "a_1",
         "isMultiKey" : false,
         "isUnique" : false,
         "isSparse" : false,
         "isPartial" : false,
         "indexVersion" : 1,
         "direction" : "forward",
         "indexBounds" : {
            "a" : [
               "[1.0, 1.0]"
            ]
         },
         "keysExamined" : 2,
         "dupsTested" : 0,
         "dupsDropped" : 0,
         "seenInvalidated" : 0
      }
   },
   "ts" : ISODate("2015-09-03T15:26:14.948Z"),
   "client" : "127.0.0.1",
   "appName" : "MongoDB Shell",
   "allUsers" : [ ],
   "user" : ""
}

如果 `scanAndOrder` 为 `假` ，MongoDB可以利用建有索引的文档顺序返回已排序的结果。¶

当一个更新操作将一个或多个文档移至磁盘上新的地方时，这个字段值为 真 。如果更新操作没有产生移动作用，那么该字段不会出现。产生移动行为的操作会比本地更新花费更多的时间，通常还会发生文档增长。

在 3.2.0 版更改: system.profile.query.skip replaces the system.profile.ntoskip field.

在 3.2.0 版更改: The information in the system.profile.ntoreturn field has been replaced by two separate fields, system.profile.query.limit and system.profile.query.batchSize. Older drivers or older versions of the mongo shell may still use ntoreturn; this will appear as system.profile.query.ntoreturn.

注解

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
在操作里更新的改变 index 的数量。改变一个索引值会消耗一点性能，因为数据库必须移掉老的值并插入新的值到B-tree索引中。
distinct
该操作为了使其他操作完成而放弃的次数。通常来说，当他们需要访问还没有完全读入内存中的数据时，操作将放弃。这使得在MongoDB为了放弃操作进行数据读取的同时，还有数据在内存中的其他操作可以完成。更多的相关信息请参见 the FAQ on when operations yield 。
getMore
group
insert
mapReduce
query
remove
该操作获取一个级锁花费的时间。对于请求多个锁的操作，比如对 local 数据库锁来更新 oplog ，该值比该操作的总长要长（即 millis ）

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.

在 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.keysExamined¶

在 3.2.0 版更改.

当MongoDB将查询的慢日志信息写入日志时， responseLength 值在 reslen 字段里。

In general, if keysExamined is much higher than nreturned, the database is scanning many index keys to find the result documents. Consider creating or adjusting indexes to improve query performance..

在 3.4 版更改.

keysExamined is available for the following commands and operations:

aggregate
find (OP_QUERY and command)
findAndModify
对任何单个操作来说，数据库profiler创建的文档包含下列字段的子集。依靠操作类型在这些文档中进行精确的字段筛选。
distinct
getMore (OP_GET_MORE and command)
geoNear
group
mapReduce
delete
update

system.profile.docsExamined¶

在 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.

在 3.4 版更改.

docsExamined is available for the following commands and operations:

aggregate
find (OP_QUERY and command)
findAndModify
对任何单个操作来说，数据库profiler创建的文档包含下列字段的子集。依靠操作类型在这些文档中进行精确的字段筛选。
distinct
getMore (OP_GET_MORE and command)
geoNear
group
mapReduce
delete
update

system.profile.moved¶

Removed in 3.4.

在 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¶: 在 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¶

在 3.2.0 版更改: Renamed from system.profile.scanAndOrder.

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.

在 3.4 版更改.

hasSortStage is available for the following commands and operations:

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

system.profile.ninserted¶: 对于像 db.eval() 这样的一些操作，客户端用 0.0.0.0:0 代替实际的客户端地址。

system.profile.nMatched¶: 2.6 新版功能.

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

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

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.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¶: 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¶

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:

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

注解

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¶

在 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.

注解

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

system.profile.execStats.stage¶

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¶: 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.appName¶: 3.4 新版功能.

The identifier of the client application which ran the operation. If the operation was run in the MongoDB shell, the appName is always "MongoDB Shell". If the operation originated from a driver, appName may be set to a custom string.

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.

← Database Profiler Disable Transparent Huge Pages (THP) →

数据库 Profiler输出¶

在进行 update 操作时传递的 <update> 文档。¶

如果 scanAndOrder 为 假 ，MongoDB可以利用建有索引的文档顺序返回已排序的结果。¶

在进行 `update` 操作时传递的 `<update>` 文档。¶

如果 `scanAndOrder` 为 `假` ，MongoDB可以利用建有索引的文档顺序返回已排序的结果。¶