数据库分析器输出
数据库分析器捕获有关读写操作、游标操作和数据库命令的数据信息。要配置数据库配置文件并设置捕获配置文件数据的阈值,请参阅数据库分析器部分。
数据库分析器会在 system.profile
集合中写入数据,这是一个固定大小集合。要查看分析器的输出,请对 system.profile
集合使用一般 MongoDB 查询。
注意
由于数据库分析器会将数据写入数据库中的 system.profile
集合,因此分析器会分析某些写入活动,即使对于只读数据库也是如此。
currentOp
数据库分析器会为 CRUD 操作报告相同的基本诊断信息,包括以下内容:
getMore
(OP_GET_MORE 和command
)
这些操作也包含在慢查询的日志中。有关慢查询日志的更多信息,请参阅 slowOpThresholdMs
。
使用 Queryable Encryption 时,针对加密集合的增删改查操作将从 system.profile
集合中省略。有关详细信息,请参阅遮蔽。
现在已无法在事务中对 system.profile
集合执行任何操作,包括读取操作。
警告
不要尝试创建名称为 system.profile
的时间序列集合或视图。如果您尝试这样做,MongoDB 6.3 及更高版本会返回 IllegalOperation
错误。早期 MongoDB 版本会因此崩溃。
输出字段
对于任何单个操作,数据库分析器创建的文档都包含以下部分字段。这些文档中的特定字段取决于操作类型。
注意
有关 MongoDB 版本的特定输出,请参阅相应版本的 MongoDB 手册。
system.profile.command
包含与此操作相关的完整命令对象的文档。
例如,以下输出包含在
test
数据库中items
集合上执行的find
操作的命令对象:"command" : { "find" : "items", "filter" : { "sku" : 1403978 }, ... "$db" : "test" } 以下示例输出包含
getMore
操作的命令对象,该命令对象由游标 ID 为19234103609
的命令在名为test
的数据库中名为items
的集合上生成:"command" : { "getMore" : NumberLong("19234103609"), "collection" : "items", "batchSize" : 10, ... "$db" : "test" }, 如果命令文档的大小超过 50 KB,则文档的格式如下:
"command" : { "$truncated": <string>, "comment": <string> } $truncated
字段包含文档的字符串概要,不包括文档的comment
字段(如果存在)。如果概要仍然超过 50 KB,则会进一步截断,在字符串末尾用省略号 (...) 表示。如果将注释传递给操作,则会出现
comment
字段。任何数据库命令都可以附加注释。
system.profile.originatingCommand
对于会从游标检索下一批结果的
"getmore"
操作,originatingCommand
字段包含最初创建该游标的完整命令对象(例如,find
或aggregate
)。
system.profile.keysExamined
MongoDB 为执行该操作而扫描的索引键的数量。
通常,如果
keysExamined
远高于nreturned
,则数据库正在扫描许多索引键以查找结果文档。请考虑创建或调整索引,以提高查询性能。keysExamined
可用于以下命令和操作:
system.profile.hasSortStage
hasSortStage
是一个布尔值,当查询无法使用索引中的排序返回请求的排序结果时,此值为true
;即MongoDB 接收到游标中包含的文档后必须对文档进行排序。此字段仅在值为true
时出现。hasSortStage
可用于以下命令和操作:getMore
(OP_GET_MORE 和command
)
system.profile.usedDisk
一个布尔值,表示是否有任何聚合阶段由于内存限制而将数据写入临时文件。
仅在
usedDisk
为 true 时显示。
system.profile.replanned
一个布尔值,表示查询系统是否逐出了缓存的计划并重新评估了所有候选计划。
仅在值为
true
时显示。
system.profile.replanReason
一个字符串,表示缓存计划被逐出的具体原因。
仅在
replanned
的值为true
时显示。
system.profile.writeConflicts
写入操作过程中遇到的冲突次数;例如,一个
update
操作尝试与另一个update
操作修改同一文档。另请参阅写冲突。
system.profile.numYield
该操作让出以允许其他操作完成的次数。通常,当操作需要访问 MongoDB 尚未完全读入内存的数据时,它们就会让出。这使得在 MongoDB 读取让出操作的数据时,其他已经在内存中有数据的操作可以完成。有关更多信息,请参阅有关操作让出时的常见问题解答。
system.profile.queryHash
从 MongoDB 8.0 开始,预先存在的
queryHash
字段被重命名为planCacheShapeHash
。如果正在使用早期版本的 MongoDB,您将看到queryHash
而不是planCacheShapeHash
。
system.profile.planCacheShapeHash
一个十六进制字符串,表示计划缓存查询结构的哈希值,并且仅依赖于计划缓存查询结构。
planCacheShapeHash
有助于识别具有相同计划缓存查询结构的慢查询,包括写入操作的查询筛选条件。注意
与任何哈希函数一样,两个不同的计划缓存查询结构可能会产生相同的哈希值。但是,不同计划缓存查询结构之间不太可能发生哈希冲突。
有关
planCacheShapeHash
和planCacheKey
的更多信息,请参阅 planCacheShapeHash 和 planCacheKey。从 MongoDB 8.0 开始,预先存在的
queryHash
字段被重命名为planCacheShapeHash
。如果正在使用早期版本的 MongoDB,您将看到queryHash
而不是planCacheShapeHash
。
system.profile.planCacheKey
与此查询关联的计划缓存条目的键的哈希值。
与
planCacheShapeHash
不同,planCacheKey
是计划缓存查询结构和该结构当前可用索引的函数。具体而言,如果添加或删除了支持查询结构的索引,则planCacheKey
值可能会更改,但planCacheShapeHash
不会更改。有关
planCacheShapeHash
和planCacheKey
的更多信息,请参阅 planCacheShapeHash 和 planCacheKey。从 MongoDB 8.0 开始,预先存在的
queryHash
字段被重命名为planCacheShapeHash
。如果正在使用早期版本的 MongoDB,您将看到queryHash
而不是planCacheShapeHash
。
system.profile.queryFramework
用于处理操作的查询框架。
system.profile.locks
system.profile.locks
会提供操作过程中各种锁类型和锁模式的信息。可能的锁类型包括:
锁类型说明ParallelBatchWriterMode
代表并行批量写入模式的锁。
在早期版本中,PBWM 信息作为
Global
锁信息的一部分进行报告。ReplicationStateTransition
表示副本集节点状态转换采用的锁。Global
代表全局锁定。Database
代表数据库锁。Collection
代表集合锁。Mutex
代表互斥锁。Metadata
代表元数据锁。DDLDatabase
表示DDL数据库锁。
版本 7.1 中的新增内容。
DDLCollection
表示DDLcollection锁。
版本 7.1 中的新增内容。
oplog
表示 oplog 上的锁。锁类型的可能锁模式如下:
锁模式说明R
代表共享(S)锁。W
代表独占 (X) 锁。r
代表意向共享(IS)锁。w
代表意图独占 (IX) 锁。针对各种锁类型返回的锁信息包括:
system.profile.locks.acquireWaitCount
该操作因锁处于冲突模式而不得不等待
acquireCount
锁获取的次数。acquireWaitCount
小于或等于acquireCount
。
system.profile.locks.timeAcquiringMicros
操作获取锁所需等待的累计时间(以微秒为单位)。
timeAcquiringMicros
除以acquireWaitCount
得出特定锁模式的大致平均等待时间。
有关锁模式的更多信息,请参阅MongoDB 使用哪种类型的锁?
system.profile.authorization
5.0.0 版本新增。
每次操作访问用户缓存的次数。只有当操作至少访问过一次用户缓存时,才会显示这些指标。
这些指标只有在启用慢操作日志或数据库性能分析时才可用。
system.profile.authorization
不包括在db.currentOp()
输出中。
system.profile.storage
system.profile.storage
信息提供了存储引擎数据的指标和操作等待时间。仅当值大于零时,才会返回特定存储指标。
system.profile.storage.data.bytesRead
该操作从磁盘读取到缓存的字节数。
从磁盘读入缓存的数据包括执行查询所需的所有内容。如果数据已在缓存中,则从磁盘读取的字节数可能为
0
。从磁盘读取的字节数超过查询到的文档的字节数:
WiredTiger 以页面为单位读取,一页可能包含一份或多份文档。如果有文档位于某页面,则该页面中的所有文档都会读入缓存并包含在
bytesRead
值中。如果缓存需要页面管理(例如,逐出或重新读取),则
bytesRead
值包括在这些操作中从磁盘读取的数据。如果索引不在缓存中或者缓存中的索引已过时,WiredTiger 会从磁盘读取几个内部页和叶子页,以重建缓存中的索引。
system.profile.responseLength
操作产生的结果文档的长度(以字节为单位)。过大的
responseLength
会影响性能。要限制查询操作结果文档的大小,可以使用以下任何一种方法:注意
当 MongoDB 将查询配置文件信息写入日志时,
responseLength
值位于名为reslen
的字段中。
system.profile.protocol
MongoDB 传输协议请求消息格式。
system.profile.millis
从
mongod
的角度来看,从操作开始到操作结束所用的时间(以毫秒为单位)。
planningTimeMicros
6.2 版本新增。
find
或aggregate
命令在查询规划中所花的时间,以微秒为单位。
system.profile.execStats
包含查询操作的执行统计信息的文档。对于其他操作,该值为空文档。
system.profile.execStats
以树的形式呈现统计信息;每个节点提供在查询操作阶段所执行操作的统计信息。注意
以下关于
execStats
的字段列表并非详尽无遗,因为返回的字段因阶段而异。
system.profile.appName
运行操作的客户端应用程序的标识符。使用
appName
连接字符串选项设置appName
字段的自定义值。
system.profile.allUsers
用于会话的经过身份验证的用户信息(用户名和数据库)的大量。 另请参阅自托管部署中的用户。
示例system.profile
文档
以下示例提供了在 system.profile
集合中找到的用于独立操作的示例文档:
system.profile
集合中的如下文档会显示 test.report
集合上的示例查询操作的指标:
{ "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, "fromMultiPlanner" : true, "numYield" : 2, "nreturned" : 101, "planCacheShapeHash" : "811451DD", "planCacheKey" : "759981BA", "queryFramework" : "classic", "locks" : { "Global" : { "acquireCount" : { "r" : NumberLong(3), "w" : NumberLong(3) } }, "Database" : { "acquireCount" : { "r" : NumberLong(3) }, "acquireWaitCount" : { "r" : NumberLong(1) }, "timeAcquiringMicros" : { "r" : NumberLong(69130694) } }, "Collection" : { "acquireCount" : { "r" : NumberLong(3) } } }, "storage" : { "data" : { "bytesRead" : NumberLong(14736), "timeReadingMicros" : NumberLong(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" }
system.profile
集合包括 getMore
操作的指标。在此示例中,getMore
返回 test.report
集合中的其他文档。
{ "op" : "getmore", "ns" : "test.report", "command" : { "getMore" : Long("33629063128"), "collection" : "report", "batchSize": 3, "lsid" : { "id": new UUID("3148c569-425c-4498-9168-5b7ee260bf27") }, "$db" : "test" }, originatingCommand: { "find: "report", "filter" : { "a" : { "$lte" : 500 } }, "lsid" : { "id" : UUID("5ccd5b81-b023-41f3-8959-bf99ed696ce9") }, "$db" : "test" }, "cursorid" : Long("33629063128"), "keysExamined" : 101, "docsExamined" : 101, "fromMultiPlanner" : true, "numYield" : 2, "nreturned" : 3, "planCacheShapeHash" : "811451DD", "planCacheKey" : "759981BA", "queryFramework": "classic" "locks" : { "Global" : { "acquireCount" : { "r" : NumberLong(3), "w" : NumberLong(3) } }, "Database" : { "acquireCount" : { "r" : NumberLong(3) }, "acquireWaitCount" : { "r" : NumberLong(1) }, "timeAcquiringMicros" : { "r" : NumberLong(69130694) } }, "Collection" : { "acquireCount" : { "r" : NumberLong(3) } } }, readConcern: {level: 'local', provenance: 'implicitDefault'}, "responseLength" : 1305014, "protocol" : "op_msg", "millis" : 69132, "planSummary" : "IXSCAN { a: 1, _id: -1 }", "execStats" : { "stage" : "FETCH", "filter" : { "a" : { "$lte" : 500 } }, "nReturned" : 101, "executionTimeMillisEstimate" : 0, "works" : 104, "advanced" : 104, "needTime" : 0, "needYield" : 0, "saveState" : 3, "restoreState" : 2, "isEOF" : 0, "direction": 'forward', "docsExamined" : 104 }, "ts" : ISODate("2019-01-14T16:57:33.450Z"), "client" : "127.0.0.1", "appName" : "MongoDB Shell", "allUsers" : [ { "user" : "someuser", "db" : "admin" } ], "user" : "someuser@admin" }
从 MongoDB 8.0 开始,预先存在的 queryHash
字段被重命名为 planCacheShapeHash
。如果正在使用早期版本的 MongoDB,您将看到 queryHash
而不是 planCacheShapeHash
。
update
(和 delete
)操作的分析器条目包含整个 update 命令。
system.profile
集合中的如下文档会显示 test.report
集合上的示例更新操作的指标:
{ "op" : "update", "ns" : "test.report", "command" : { "q" : { }, "u" : { "$rename" : { "a" : "b" } }, "multi" : true, "upsert" : false }, "keysExamined" : 0, "docsExamined" : 25000, "nMatched" : 25000, "nModified" : 25000, "keysInserted" : 25000, "keysDeleted" : 25000000, "numYield" : 6985, "locks" : { "Global" : { "acquireCount" : { "r" : NumberLong(6986), "w" : NumberLong(13972) } }, "Database" : { "acquireCount" : { "w" : NumberLong(6986) }, "acquireWaitCount" : { "w" : NumberLong(1) }, "timeAcquiringMicros" : { "w" : NumberLong(60899375) } }, "Collection" : { "acquireCount" : { "w" : NumberLong(6986) } }, "Mutex" : { "acquireCount" : { "r" : NumberLong(25000) } } }, "storage" : { "data" : { "bytesRead" : NumberLong(126344060), "bytesWritten" : NumberLong(281834762), "timeReadingMicros" : NumberLong(94549), "timeWritingMicros" : NumberLong(139361) } }, "millis" : 164687, "planningTimeMicros" : 129, "planSummary" : "COLLSCAN", "execStats" : { "stage" : "UPDATE", "nReturned" : 0, "executionTimeMillisEstimate" : 103771, "works" : 25003, "advanced" : 0, "needTime" : 25002, "needYield" : 0, "saveState" : 6985, "restoreState" : 6985, "isEOF" : 1, "nMatched" : 25000, "nWouldModify" : 25000, "wouldInsert" : false, "inputStage" : { "stage" : "COLLSCAN", "nReturned" : 25000, "executionTimeMillisEstimate" : 0, "works" : 25002, "advanced" : 25000, "needTime" : 1, "needYield" : 0, "saveState" : 31985, "restoreState" : 31985, "isEOF" : 1, "direction" : "forward", "docsExamined" : 25000 } }, "ts" : ISODate("2019-01-14T23:33:01.806Z"), "client" : "127.0.0.1", "appName" : "MongoDB Shell", "allUsers" : [ { "user" : "someuser", "db" : "admin" } ], "user" : "someuser@admin" }