currentOp
Definition
Syntax
The command has the following syntax:
db.adminCommand( { currentOp: 1 } )
Note
Starting in MongoDB 5.0, the $currentOp
aggregation
stage is used when running the helper method db.currentOp()
with mongosh
.
Given this, in the 5.0 version of the shell and with mongosh,
db.currentOp()
result sets are not subject to the
16MB BSON document return size
document return size limit for documents of the previous legacy
mongo
versions.
Behavior
currentOp
must run against the admin
database, and
it can accept several optional fields.
Field | Description |
---|---|
"$ownOps" | Boolean. If set to On |
"$all" | Boolean. If set to
|
<filter> | Specify filter conditions on the Output Fields.
See Examples. |
comment | Optional. A user-provided comment to attach to this command. Once set, this comment appears alongside records of this command in the following locations:
A comment can be any valid BSON type (string, integer, object, array, etc). |
currentOp
and the database profiler report
the same basic diagnostic information for CRUD operations, including
the following:
getMore
(OP_GET_MORE andcommand
)
These operations are also included in the logging of
slow queries. See slowOpThresholdMs
for
more information about slow query logging.
Access Control
On systems running with authorization
, the user
must have access that includes the inprog
privilege
action.
Users can use
$ownOps
on mongod
instances to view their own
operations without the inprog
privilege action.
db.adminCommand( { currentOp: 1, "$ownOps": 1 } )
Examples
The following examples use the currentOp
command with
various query documents to filter the output.
Display All Current Operations
db.adminCommand( { currentOp: true, "$all": true } )
Write Operations Waiting for a Lock
The following example returns information on all write operations that are waiting for a lock:
db.adminCommand( { currentOp: true, "waitingForLock" : true, $or: [ { "op" : { "$in" : [ "insert", "update", "remove" ] } }, { "command.findandmodify": { $exists: true } } ] } )
Active Operations with no Yields
The following example returns information on all active running operations that have never yielded:
db.adminCommand( { currentOp: true, "active" : true, "numYields" : 0, "waitingForLock" : false } )
Active Operations on a Specific Database
The following example returns information on all active operations for
database db1
that have been running longer than 3 seconds:
db.adminCommand( { currentOp: true, "active" : true, "secs_running" : { "$gt" : 3 }, "ns" : /^db1\./ } )
Active Indexing Operations
The following example returns information on index creation operations:
db.adminCommand( { currentOp: true, $or: [ { op: "command", "command.createIndexes": { $exists: true } }, { op: "none", "msg" : /^Index Build/ } ] } )
Output Example
The following is a prototype of the currentOp
output when run on a standalone:
{ "inprog": [ { "type" : <string>, "host" : <string>, "desc" : <string>, "connectionId" : <number>, "client" : <string>, "appName" : <string>, "clientMetadata" : <document>, "active" : <boolean>, "currentOpTime" : <string>, "effectiveUsers" : [ { "user" : <string>, "db" : <string> } ], "opid" : <number>, "lsid" : { "id" : <UUID>, "uid" : <BinData> }, "secs_running" : <NumberLong()>, "microsecs_running" : <number>, "op" : <string>, "ns" : <string>, "command" : <document>, "planSummary": <string>, "cursor" : { // only for getMore operations "cursorId" : <NumberLong()>, "createdDate" : <ISODate()>, "lastAccessDate" : <ISODate()>, "nDocsReturned" : <NumberLong()>, "nBatchesReturned" : <NumberLong()>, "noCursorTimeout" : <boolean>, "tailable" : <boolean>, "awaitData" : <boolean>, "originatingCommand" : <document>, "planSummary" : <string>, "operationUsingCursorId" : <NumberLong()> }, "msg": <string>, "progress" : { "done" : <number>, "total" : <number> }, "killPending" : <boolean>, "numYields" : <number>, "dataThroughputLastSecond" : <number>, "dataThroughputAverage" : <number>, "waitingForLatch" : { "timestamp" : <ISODate()>, "captureName" : <string> }, "locks" : { "ParallelBatchWriterMode" : <string>, "ReplicationStateTransition" : <string>, "Global" : <string>, "Database" : <string>, "Collection" : <string>, "Metadata" : <string>, "oplog" : <string> }, "waitingForLock" : <boolean>, "lockStats" : { "ParallelBatchWriterMode" : { "acquireCount": { "r": <NumberLong>, "w": <NumberLong>, "R": <NumberLong>, "W": <NumberLong> }, "acquireWaitCount": { "r": <NumberLong>, "w": <NumberLong>, "R": <NumberLong>, "W": <NumberLong> }, "timeAcquiringMicros" : { "r" : NumberLong(0), "w" : NumberLong(0), "R" : NumberLong(0), "W" : NumberLong(0) }, "deadlockCount" : { "r" : NumberLong(0), "w" : NumberLong(0), "R" : NumberLong(0), "W" : NumberLong(0) } }, "ReplicationStateTransition" : { ... }, "Global": { ... }, "Database" : { ... }, ... } }, ... ], "fsyncLock": <boolean>, "info": <string>, "ok": <num> }
The following is a prototype of the currentOp
output when run on a primary of a replica set:
{ "inprog": [ { "type" : <string>, "host" : <string>, "desc" : <string>, "connectionId" : <number>, "client" : <string>, "appName" : <string>, "clientMetadata" : <document>, "lsid" : { "id" : <UUID>, "uid" : <BinData> }, "transaction" : { "parameters" : { "txnNumber" : <NumberLong()>, "autocommit" : <boolean>, "readConcern" : { "level" : <string> } }, "readTimestamp" : <Timestamp>, "startWallClockTime" : <string>, "timeOpenMicros" : <NumberLong()>, "timeActiveMicros" : <NumberLong()>, "timeInactiveMicros" : <NumberLong()>, "expiryTime" : <string>, }, "active" : <boolean>, "currentOpTime" : <string>, "effectiveUsers" : [ { "user" : <string>, "db" : <string> } ], "opid" : <number>, "secs_running" : <NumberLong()>, "microsecs_running" : <number>, "op" : <string>, "ns" : <string>, "command" : <document>, "originatingCommand" : <document>, "planSummary": <string>, "prepareReadConflicts" : <NumberLong()>, "writeConflicts" : <NumberLong()>, "cursor" : { // only for getMore operations "cursorId" : <NumberLong()>, "createdDate" : <ISODate()>, "lastAccessDate" : <ISODate()>, "nDocsReturned" : <NumberLong()>, "nBatchesReturned" : <NumberLong()>, "noCursorTimeout" : <boolean>, "tailable" : <boolean>, "awaitData" : <boolean>, "originatingCommand" : <document>, "planSummary" : <string>, "operationUsingCursorId" : <NumberLong()> }, "msg": <string>, "progress" : { "done" : <number>, "total" : <number> }, "killPending" : <boolean>, "numYields" : <number>, "dataThroughputLastSecond" : <number>, "dataThroughputAverage" : <number>, "waitingForLatch" : { "timestamp" : <ISODate()>, "captureName" : <string> }, "locks" : { "ParallelBatchWriterMode" : <string>, "ReplicationStateTransition" : <string>, "Global" : <string>, "Database" : <string>, "Collection" : <string>, "Metadata" : <string>, "oplog" : <string> }, "waitingForLock" : <boolean>, "lockStats" : { "ParallelBatchWriterMode" : { "acquireCount": { "r": <NumberLong>, "w": <NumberLong>, "R": <NumberLong>, "W": <NumberLong> }, "acquireWaitCount": { "r": <NumberLong>, "w": <NumberLong>, "R": <NumberLong>, "W": <NumberLong> }, "timeAcquiringMicros" : { "r" : NumberLong(0), "w" : NumberLong(0), "R" : NumberLong(0), "W" : NumberLong(0) }, "deadlockCount" : { "r" : NumberLong(0), "w" : NumberLong(0), "R" : NumberLong(0), "W" : NumberLong(0) } }, "ReplicationStateTransition" : { ... }, "Global" : { ... }, "Database" : { ... }, ... } }, ... ], "fsyncLock": <boolean>, "info": <string>, "ok": <num>, "operationTime": <timestamp>, "$clusterTime": <document> }
The following is an example of the currentOp
output when run on a mongos
of a sharded
cluster (Fields may vary depending on the operation being
reported):
{ "inprog": [ { "shard": <string>, "type" : <string>, "host" : <string>, "desc" : <string>, "connectionId" : <number>, "client_s" : <string>, "appName" : <string>, "clientMetadata" : <document>, "lsid" : { "id" : <UUID>, "uid" : <BinData> }, "transaction" : { "parameters" : { "txnNumber" : <NumberLong()>, "autocommit" : <boolean>, "readConcern" : { "level" : <string> } }, "readTimestamp" : <Timestamp>, "startWallClockTime" : <string>, "timeOpenMicros" : <NumberLong()>, "timeActiveMicros" : <NumberLong()>, "timeInactiveMicros" : <NumberLong()>, "expiryTime" : <string>, }, "active" : <boolean>, "currentOpTime" : <string>, "effectiveUsers" : [ { "user" : <string>, "db" : <string> } ], "runBy" : [ { "user" : <string>, "db" : <string> } ], "twoPhaseCommitCoordinator" : { "lsid" : { "id" : <UUID>, "uid" : <BinData> }, "txnNumber" : <NumberLong>, "numParticipants" : <NumberLong>, "state" : <string>, "commitStartTime" : <ISODate>, "hasRecoveredFromFailover" : <boolean>, "stepDurations" : <document>, "decision" : <document>, "deadline" : <ISODate> } "opid" : <string>, "secs_running" : <NumberLong()>, "microsecs_running" : <number>, "op" : <string>, "ns" : <string>, "command" : <document>, "configTime" : <Timestamp>, // Starting in 5.0 "topologyTime" : <Timestamp>, // Starting in 5.0 "planSummary": <string>, "prepareReadConflicts" : <NumberLong()>, "writeConflicts" : <NumberLong()>, "cursor" : { // only for getMore operations "cursorId" : <NumberLong()>, "createdDate" : <ISODate()>, "lastAccessDate" : <ISODate()>, "nDocsReturned" : <NumberLong()>, "nBatchesReturned" : <NumberLong()>, "noCursorTimeout" : <boolean>, "tailable" : <boolean>, "awaitData" : <boolean>, "originatingCommand" : <document>, "planSummary" : <string>, "operationUsingCursorId" : <NumberLong()> }, "msg": <string>, "progress" : { "done" : <number>, "total" : <number> }, "killPending" : <boolean>, "numYields" : <number>, "dataThroughputLastSecond" : <number>, "dataThroughputAverage" : <number>, "waitingForLatch" : { "timestamp" : <ISODate()>, "captureName" : <string> }, "locks" : { "ParallelBatchWriterMode" : <string>, "ReplicationStateTransition" : <string>, "Global" : <string>, "Database" : <string>, "Collection" : <string>, "Metadata" : <string>, "oplog" : <string> }, "waitingForLock" : <boolean>, "lockStats" : { "ParallelBatchWriterMode": { "acquireCount": { "r": <NumberLong>, "w": <NumberLong>, "R": <NumberLong>, "W": <NumberLong> }, "acquireWaitCount": { "r": <NumberLong>, "w": <NumberLong>, "R": <NumberLong>, "W": <NumberLong> }, "timeAcquiringMicros" : { "r" : NumberLong(0), "w" : NumberLong(0), "R" : NumberLong(0), "W" : NumberLong(0) }, "deadlockCount" : { "r" : NumberLong(0), "w" : NumberLong(0), "R" : NumberLong(0), "W" : NumberLong(0) } }, "ReplicationStateTransition" : { ... }, "Global" : { ... }, "Database" : { ... }, ... } }, ... ], "ok": <num>, "operationTime": <timestamp>, "$clusterTime": <document> }
Output Fields
currentOp.type
New in version 4.2.
The type of operation. Values are either:
op
idleSession
idleCursor
If the
currentOp.type
isop
,currentOp.op
provides details on the specific operation.
currentOp.desc
A description of the client. This string includes the
connectionId
.
currentOp.client
A string with information about where the operation originated.
For multi-document transactions,
client
stores information about the most recent client to run an operation inside the transaction.
currentOp.appName
The identifier of the client application which ran the operation. Use the
appName
connection string option to set a custom value for theappName
field.
currentOp.clientMetadata
Additional information on the client.
For multi-document transactions,
client
stores information about the most recent client to run an operation inside the transaction.
currentOp.effectiveUsers
An array that contains a document for each user associated with the operation. Each user document contains the
user
name and the authenticationdb
.New in version 4.2.
currentOp.runBy
An array that contains a document for each user who is impersonating the
effectiveUser(s)
for the operation. The runBy document contains theuser
name and the authenticationdb
. In general, the runBy user is the__system
user; e.g."runBy" : [ { "user" : "__system", "db" : "local" } ] Only available on sharded clusters
New in version 4.2.
currentOp.transaction
A document that contains multi-document transaction information.
Only present if the operation is part of a multi-document transaction.
currentOp.transaction.parameters
A document that contains information on multi-document transaction.
Only present if the operation is part of a multi-document transaction.
currentOp.transaction.parameters.txnNumber
The transaction number.
Only present if the operation is part of a multi-document transaction.
currentOp.transaction.parameters.autocommit
A boolean flag that indicates if autocommit is on for the transaction.
Only present if the operation is part of a multi-document transaction.
currentOp.transaction.parameters.readConcern
The read concern for the transaction.
Multi-document transactions support read concern
"snapshot"
,"local"
, and"majority"
.Only present if the operation is part of a multi-document transaction.
currentOp.transaction.readTimestamp
The timestamp of the snapshot being read by the operations in the transaction.
Only present if the operation is part of a multi-document transaction.
currentOp.transaction.startWallClockTime
The date and time (with time zone) of the transaction start.
Only present if the operation is part of a multi-document transaction.
currentOp.transaction.timeOpenMicros
The duration of the transaction in microseconds.
The
timeActiveMicros
value added to thetimeInactiveMicros
should equal thetimeOpenMicros
.Only present if the operation is part of a multi-document transaction.
currentOp.transaction.timeActiveMicros
The total amount of time that the transaction has been active; i.e. when the transaction had operations running.
The
timeActiveMicros
value added to thetimeInactiveMicros
should equal thetimeOpenMicros
.Only present if the operation is part of a multi-document transaction.
currentOp.transaction.timeInactiveMicros
The total amount of time that the transaction has been inactive; i.e. when the transaction had no operations running.
The
timeInactiveMicros
value added to thetimeActiveMicros
should equal thetimeOpenMicros
.Only present if the operation is part of a multi-document transaction.
currentOp.transaction.expiryTime
The date and time (with time zone) when the transaction will time out and abort.
The
currentOp.transaction.expiryTime
equals thecurrentOp.transaction.startWallClockTime
+ thetransactionLifetimeLimitSeconds
.For more information, seee Runtime Limit for transactions.
Only present if the operation is part of a multi-document transaction.
currentOp.twoPhaseCommitCoordinator
Information on either:
The commit coordination metrics for a transaction whose write operations span multiple shards.
Commit coordination is handled by a shard, and
currentOp
(run either on amongos
or a shard member) returns a shard's coordination information only for those transactions currently being coordinated by that shard.To filter for just the commit coordination metrics:
db.currentOp( { desc: "transaction coordinator" }) A specific commit coordination operation (i.e.
currentOp.type
isop
andcurrentOp.desc
is"TransactionCoordinator"
) spawned by the transaction coordinator.
currentOp.twoPhaseCommitCoordinator.lsid
The session identifier for the multi-shard transaction.
The combination of the
lsid
andtxnNumber
identifies the transaction.Available for both the commit coordination metrics and for specific coordination operation.
currentOp.twoPhaseCommitCoordinator.txnNumber
The transaction number for the multi-shard transaction.
The combination of the
txnNumber
andlsid
identifies the transaction.Available for both the commit coordination metrics and for specific coordination operation.
currentOp.twoPhaseCommitCoordinator.action
The specific commit coordination operation spawned by the transaction coordinator:
"sendingPrepare"
"sendingCommit"
"sendingAbort"
"writingParticipantList"
"writingDecision"
"deletingCoordinatorDoc"
Only available for specific coordination operation.
currentOp.twoPhaseCommitCoordinator.startTime
The start date and time of the
action
.Only available for specific coordination operation.
currentOp.twoPhaseCommitCoordinator.numParticipants
Number of shards participating in this commit.
Only available for the commit coordination metrics.
currentOp.twoPhaseCommitCoordinator.state
The current step/state of the commit coordination process.
Step/stageDescriptioninactive
Not actively part of a commit.writingParticipantList
Writing a local record of the list of shards that are part of this multi-shard transaction.waitingForVotes
Waiting for the participants to respond with vote to commit or abort.writingDecision
Writing a local record of the coordinator's decision to commit or abort based on votes.waitingForDecisionAck
Waiting for participants to acknowledge the coordinator's decision to commit or abort.deletingCoordinatorDoc
Deleting the local record of commit decision.Only available for the commit coordination metrics.
currentOp.twoPhaseCommitCoordinator.commitStartTime
The date and time when the commit started.
Only available for the commit coordination metrics.
currentOp.twoPhaseCommitCoordinator.hasRecoveredFromFailover
A boolean that indicates whether the commit coordination was restarted due to failover on the shard that is coordinating the commit.
If
hasRecoveredFromFailover
is true, then the times specified incurrentOp.twoPhaseCommitCoordinator.stepDurations
may not be accurate for all steps.Only available for the commit coordination metrics.
currentOp.twoPhaseCommitCoordinator.stepDurations
A document that contains the duration, in microseconds, of the commit coordination
steps/state
completed or in progress:"stepDurations" : { "writingParticipantListMicros" : NumberLong(17801), "totalCommitDurationMicros" : NumberLong(42488463), "waitingForVotesMicros" : NumberLong(30378502), "writingDecisionMicros" : NumberLong(15015), "waitingForDecisionAcksMicros" : NumberLong(12077145), "deletingCoordinatorDocMicros" : NumberLong(6009) }, If
currentOp.twoPhaseCommitCoordinator.hasRecoveredFromFailover
is true, then the times specified instepDurations
may not be accurate for all steps.For a coordinator in an
inactive
state, the document is empty:"stepDurations" : { } Only available for the commit coordination metrics.
currentOp.twoPhaseCommitCoordinator.decision
A document that contains the commit/abort decision, for example:
For a commmit decision:
"decision" : { "decision" : "commit", "commitTimestamp" : Timestamp(1572034669, 3) } For an abort decision:
"decision" : { "decision" : "abort", "abortStatus" : { "code" : 282, "codeName" : "TransactionCoordinatorReachedAbortDecision", "errmsg" : "Transaction exceeded deadline" } }
Only available for the commit coordination metrics.
currentOp.twoPhaseCommitCoordinator.deadline
The date and time by which the commit must finish.
Only available for the commit coordination metrics.
currentOp.opid
The identifier for the operation. You can pass this value to
db.killOp()
inmongosh
to terminate the operation.Warning
Terminate running operations with extreme caution. Only use
db.killOp()
to terminate operations initiated by clients and do not terminate internal database operations.
currentOp.active
A boolean value specifying whether the operation has started. Value is
true
if the operation has started orfalse
if the operation is idle, such as an idle connection or an internal thread that is currently idle. An operation can be active even if the operation has yielded to another operation. For some inactive background threads, such as an inactivesignalProcessingThread
, MongoDB suppresses various empty fields.
currentOp.secs_running
The duration of the operation in seconds. MongoDB calculates this value by subtracting the current time from the start time of the operation.
Only appears if the operation is running; i.e. if
active
istrue
.
currentOp.microsecs_running
The duration of the operation in microseconds. MongoDB calculates this value by subtracting the current time from the start time of the operation.
Only appears if the operation is running; i.e. if
active
istrue
.
currentOp.op
A string that identifies the specific operation type. Only present if
currentOp.type
isop
.The possible values are:
"none"
"update"
"insert"
"query"
"command"
"getmore"
"remove"
"killcursors"
"query"
operations include read operations."command"
operations include most commands such as thecreateIndexes
andfindAndModify
.
currentOp.ns
The namespace the operation targets. A namespace consists of the database name and the collection name concatenated with a dot (
.
); that is,"<database>.<collection>"
.
currentOp.command
A document containing the full command object associated with this operation.
For example, the following output contains the command object for a
find
operation on a collection nameditems
in a database namedtest
:"command" : { "find" : "items", "filter" : { "sku" : 1403978 }, ... "$db" : "test" } The following example output contains the command object for a
getMore
operation generated by a command with cursor ID19234103609
on a collection nameditems
in a database namedtest
:"command" : { "getMore" : NumberLong("19234103609"), "collection" : "items", "batchSize" : 10, ... "$db" : "test" }, If the command document exceeds 1 kilobyte, the document has the following form:
"command" : { "$truncated": <string>, "comment": <string> } The
$truncated
field contains a string summary of the document excluding the document'scomment
field if present. If the summary still exceeds 1 kilobyte 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.
currentOp.planSummary
Specifies whether the cursor uses a collection scan (
COLLSCAN
) or an index scan (IXSCAN { ... }
).The
IXSCAN
also includes the specification document of the index used.
currentOp.prepareReadConflicts
The number of times the current operation had to wait for a prepared transaction with a write to commit or abort.
While waiting, the current operation continues to hold any necessary locks and storage engine resources.
New in version 4.2.
currentOp.writeConflicts
The number of times the current operation conflicted with another write operation on the same document.
New in version 4.2.
currentOp.cursor
New in version 4.2.
A document that contains the cursor information for
getmore
operations; i.e. whereop
isgetmore
.If reporting on a
getmore
operation before thegetmore
has accessed its cursor information, thecursor
field is not available.currentOp.cursor.nDocsReturned
New in version 4.2.
The cumulative number of documents returned by the cursor.
currentOp.cursor.nBatchesReturned
New in version 4.2.
The curmulative number of batches returned by the cursor.
currentOp.cursor.noCursorTimeout
New in version 4.2.
The flag that indicates that the cursor will not timeout when idle; i.e. if the cursor has the
noTimeout
option set.If true, the cursor does not time out when idle.
If false, the cursor will time out when idle.
currentOp.cursor.tailable
New in version 4.2.
The flag that indicates if the cursor is a tailable cursor for a capped collection. Tailable cursors remain open after the client exhausts the results in the initial cursor.
currentOp.cursor.awaitData
New in version 4.2.
The flag that indicates whether the tailable cursor should temporarily block a
getMore
command on the cursor while waiting for new data rather than returning no data.For non-tailable cursors, the value is always false.
currentOp.cursor.originatingCommand
New in version 4.2.
The
originatingCommand
field contains the full command object (e.g.find
oraggregate
) which originally created the cursor.Note
Starting in version 4.2, MongoDB now returns
originatingCommand
field as a nested field in the newcursor
field. In previous versions, theoriginatingCommand
was a top-level field for the associated"getmore"
document.
currentOp.waitingForLatch
The
waitingForLatch
document is only available if the operation is waiting to acquire an internal locking primitive (a.k.a. a latch) or for an internal condition to be met.For example,
"waitingForLatch" : { "timestamp" : ISODate("2020-03-19T23:25:58.412Z"), "captureName" : "FutureResolution", }, Output FieldDescriptiontimestampThe date and time at which the operation started to wait.captureNameThe internal name of the section where the operation is currently blocked.New in version 4.2.2.
currentOp.locks
The
locks
document reports the type and mode of locks the operation currently holds. The possible lock types are as follows:Lock TypeDescriptionParallelBatchWriterMode
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 transitions.Global
Represents global lock.Database
Represents database lock.Collection
Represents collection lock.Mutex
Represents mutex.Metadata
Represents metadata lock.oplog
Represents lock on the oplog.The possible modes are as follows:
Lock ModeDescriptionR
Represents Shared (S) lock.W
Represents Exclusive (X) lock.r
Represents Intent Shared (IS) lock.w
Represents Intent Exclusive (IX) lock.
currentOp.waitingForLock
Returns a boolean value.
waitingForLock
istrue
if the operation is waiting for a lock andfalse
if the operation has the required lock.
currentOp.msg
The
msg
provides a message that describes the status and progress of the operation. In the case of indexing or mapReduce operations, the field reports the completion percentage.
currentOp.progress
Reports on the progress of mapReduce or indexing operations. The
progress
fields corresponds to the completion percentage in themsg
field. Theprogress
specifies the following information:
currentOp.killPending
Returns
true
if the operation is currently flagged for termination. When the operation encounters its next safe termination point, the operation will terminate.
currentOp.numYields
numYields
is a counter that reports the number of times the operation has 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 quickly while MongoDB reads in data for the yielding operation.
currentOp.dataThroughputLastSecond
Amount of data (in MiB) processed by the
validate
operation in the last second. Only available for avalidate
operation that is currently scanning documents. For example:"msg" : "Validate: scanning documents Validate: scanning documents: 7258/24000 30%", "progress" : { "done" : 7258, "total" : 24000 }, "numYields" : 0, "dataThroughputLastSecond" : 15.576952934265137, "dataThroughputAverage" : 15.375944137573242,
currentOp.dataThroughputAverage
The average amount of data (in MiB) processed by the
validate
operation. Only available for avalidate
operation that is currently scanning documents. For example:"msg" : "Validate: scanning documents Validate: scanning documents: 7258/24000 30%", "progress" : { "done" : 7258, "total" : 24000 }, "numYields" : 0, "dataThroughputLastSecond" : 15.576952934265137, "dataThroughputAverage" : 15.375944137573242,
currentOp.fsyncLock
Specifies if database is currently locked for
fsync write/snapshot
.Only appears if locked; i.e. if
fsyncLock
istrue
.
currentOp.info
Information regarding how to unlock database from
db.fsyncLock()
. Only appears iffsyncLock
istrue
.
currentOp.lockStats
For each lock type and mode (see
currentOp.locks
for descriptions of lock types and modes), returns the following information:currentOp.lockStats.acquireCount
Number of times the operation acquired the lock in the specified mode.
currentOp.lockStats.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
.
currentOp.lockStats.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.
currentOp.waitingForFlowControl
A boolean that indicates if the operation is in the process of waiting for flow control.
New in version 4.2.
currentOp.flowControlStats
The flow control statistics for this operation.
New in version 4.2.
currentOp.flowControlStats.acquireCount
The number of times this operation acquired a ticket.
New in version 4.2.
currentOp.totalOperationTimeElapsed
The total time elapsed, in seconds, for the current resharding operation. The time is set to 0 when a new resharding operation starts.
Only present if a resharding operation is taking place.
New in version 5.0.
currentOp.remainingOperationTimeEstimated
remainingOperationTimeEstimatedSecs
: estimated time remaining in seconds for the current resharding operation. It is returned as-1
when a new resharding operation starts.Starting in:
MongoDB 5.0, but before MongoDB 6.1,
remainingOperationTimeEstimatedSecs
is only available on a recipient shard during a resharding operation.MongoDB 6.1,
remainingOperationTimeEstimatedSecs
is also available on the coordinator during a resharding operation.
The resharding operation performs these phases in order:
The clone phase duplicates the current collection data.
The catch-up phase applies any pending write operations to the resharded collection.
remainingOperationTimeEstimatedSecs
is set to a pessimistic time estimate:The catch-up phase time estimate is set to the clone phase time, which is a relatively long time.
In practice, if there are only a few pending write operations, the actual catch-up phase time is relatively short.
New in version 5.0.
currentOp.approxDocumentsToCopy
The approximate number of documents to be copied from the donor shards to the recipient shards during the resharding operation. This number is an estimate that is set at the beginning of the resharding operation and does not change after it has been set. The number is set to 0 when a new resharding operation starts. It is possible for
$currentOp.documentsCopied
and$currentOp.bytesCopied
to end up exceeding$currentOp.approxDocumentsToCopy
and$currentOp.approxBytesToCopy
, respectively, if the post-resharding data distribution is not perfectly uniform.Only present on a recipient shard when a resharding operation is taking place.
New in version 5.0.
currentOp.documentsCopied
The number of documents copied form donor shards to recipient shards during the resharding operation. The number is set to 0 when a new resharding operation starts.
Only present on a recipient shard when a resharding operation is taking place.
New in version 5.0.
currentOp.approxBytesToCopy
The approximate number of bytes to be copied from the donor shards to the recipient shards during the resharding operation. This number is an estimate that is set at the beginning of the resharding operation and does not change after it has been set. The number is set to 0 when a new resharding operation starts. It is possible for
$currentOp.documentsCopied
and$currentOp.bytesCopied
to end up exceeding$currentOp.approxDocumentsToCopy
and$currentOp.approxBytesToCopy
, respectively, if the post-resharding data distribution is not perfectly uniform.Only present on a recipient shard when a resharding operation is taking place.
New in version 5.0.
currentOp.bytesCopied
The number of bytes copied from donor shards to recipient shards during the resharding operation. The number is set to 0 when a new resharding operation starts.
Only present on a recipient shard when a resharding operation is taking place.
New in version 5.0.
currentOp.totalCopyTimeElapsed
The total elapsed time, in seconds, for ongoing data copy tasks from donor shards to recipient shards for the current resharding operation. The time is set to 0 when a new resharding operation starts.
Only present on a recipient shard when a resharding operation is taking place.
New in version 5.0.
currentOp.oplogEntriesFetched
The number of entries fetched from the oplog for the current resharding operation. The number is set to 0 when a new resharding operation starts.
Only present on a recipient shard when a resharding operation is taking place.
New in version 5.0.
currentOp.oplogEntriesApplied
The number of entries applied to the oplog for the current resharding operation. The number is set to 0 when a new resharding operation starts.
Only present on a recipient shard when a resharding operation is taking place.
New in version 5.0.
currentOp.totalApplyTimeElapsed
The total elapsed time, in seconds, for the apply step of the current resharding operation. In the apply step, recipient shards apply oplog entries to modify their data based on new incoming writes from donor shards. The time is set to 0 when a new resharding operation starts.
Only present on a recipient shard when a resharding operation is taking place.
New in version 5.0.
currentOp.countWritesDuringCriticalSection
The number of writes perfomed in the critical section for the current resharding operation. The critical section prevents new incoming writes to the collection currently being resharded. The number is set to 0 when a new resharding operation starts.
Only present on a donor shard when a resharding operation is taking place.
New in version 5.0.
currentOp.totalCriticalSectionTimeElapsed
The total elapsed time, in seconds, for the critical section of the current resharding operation. The critical section prevents new incoming writes to the collection currently being resharded. The time is set to 0 when a new resharding operation starts.
Only present on a donor shard when a resharding operation is taking place.
New in version 5.0.
currentOp.donorState
The current state of a donor shard for the resharding operation. The state is set to
unused
when a new resharding operation starts.Only present on a donor shard when a resharding operation is taking place.
StateDescriptionunused
The resharding operation is about to start or recovering from a primary failover.preparing-to-donate
The donor shard is preparing to donate data to the recipient shards.donating-initial-data
The donor shard is donating data to the recipient shards.donating-oplog-entries
The donor shard is donating oplog entries to the recipient shards.preparing-to-block-writes
The donor shard is about to prevent new incoming write operations to the collection that is being resharded.error
An error occurred during the resharding operation.blocking-writes
The donor shard is preventing new incoming write operations and the donor shard has notified all recipient shards that new incoming writes are prevented.done
The donor shard has dropped the old sharded collection and the resharding operation is complete.New in version 5.0.
currentOp.recipientState
The current state of a recipient shard for a resharding operation. The state is set to
unused
when a new resharding operation starts.Only present on a donor shard when a resharding operation is taking place.
StateDescriptionunused
The resharding operation is about to start or recovering from a primary failover.awaiting-fetch-timestamp
The recipient shard is waiting for the donor shards to be prepared to donate their data.creating-collection
The recipient shard is creating the new sharded collection.cloning
The recipient shard is receiving data from the donor shards.applying
The recipient shard is applying oplog entries to modify its copy of the data based on the new incoming writes from donor shards.error
An error occurred during the resharding operation.strict-consistency
The recipient shard has all data changes stored in a temporary collection.done
The resharding operation is complete.New in version 5.0.
currentOp.coordinatorState
The state of the resharding coordinator for the current resharding operation. The resharding coordinator is an operation that runs on the config server primary. The state is set to
unused
when a new resharding operation starts.Only present on the coordinating config server.
StateDescriptionunused
The resharding operation is about to start or recovering from a primary failover.initializing
The resharding coordinator has inserted the coordinator document intoconfig.reshardingOperations
and has added thereshardingFields
to theconfig.collections
entry for the original collection.preparing-to-donate
The resharding coordinator
has created a
config.collections
entry for the temporary resharding collection.has inserted entries into
config.chunks
for ranges based on the new shard key.has inserted entries into
config.tags
for any zones associated with the new shard key.
The coordinator informs participant shards to begin the resharding operation. The coordinator then waits until all donor shards have picked a
minFetchTimestamp
and are ready to donate.cloning
The resharding coordinator informs donor shards to donate data to recipient shards. The coordinator waits for all recipients to finish cloning the data from the donor.applying
The resharding coordinator informs recipient shards to modify their copies of data based on new incoming writes from donor shards. The coordinator waits for all recipients to finish applying oplog entries.blocking-writes
The resharding coordinator informs donor shards to prevent new incoming write operations to the collection being resharded. The coordinator then waits for all recipients to have all data changes.aborting
An unrecoverable error occurred during the resharding operation or theabortReshardCollection
command (or thesh.abortReshardCollection()
method) was run.committing
The resharding coordinator removes theconfig.collections
entry for the temporary resharding collection. The coordinator then adds therecipientFields
to the source collection's entry.New in version 5.0.
currentOp.opStatus
The current state of a resharding operation.
Only present if a resharding operation is taking place. Once the operation has completed, the operation is removed from
currentOp
output.StateDescriptionactively running
The resharding operation is actively running.success
The resharding operation has succeeded.failure
The resharding operation has failed.canceled
The resharding operation was canceled.New in version 5.0.