Definition
currentOpDeprecated since version 6.2.
In versions 6.2 and later use the
$currentOpaggregation stage.Returns a document that contains information on in-progress operations for the
mongodinstance.The
currentOpdatabase command is deprecated since version 6.2. Use the$currentOpaggregation stage instead of thecurrentOpcommand and itsmongoshhelper methoddb.currentOp().
Compatibility
This command is available in deployments hosted in the following environments:
MongoDB Atlas: The fully managed service for MongoDB deployments in the cloud
Note
This command is supported in all MongoDB Atlas clusters. For information on Atlas support for all commands, see Unsupported Commands.
MongoDB Enterprise: The subscription-based, self-managed version of MongoDB
MongoDB Community: The source-available, free-to-use, and self-managed version of MongoDB
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 |
|---|---|
| Boolean. If set to On |
| Boolean. If set to
|
<filter> | Specify filter conditions on the Output Fields. See Examples. |
| 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.
Redaction
When using Queryable Encryption,
currentOp operations with the encryptionInformation option
redact certain information:
The output omits all fields after
"command".The output redacts
"command"to include only the first element,$comment, and$db.
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.getSiblingDB("admin").aggregate( [ { $currentOp : { idleConnections: true } }, { $match: { $or: [ { "op": "command", "command.createIndexes": { $exists: true } }, { "op": "none", "msg": /^Index Build/ } ] } } ] )
MongoDB marks index builds waiting on commit quorum to complete the operation as an
idle connection by setting the active field to false. The idleConnections: true
setting includes these idle connections in the $currentOp output.
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" : <Long()>, "microsecs_running" : <number>, "op" : <string>, "ns" : <string>, "command" : <document>, "queryFramework" : <string>, "planSummary": <string>, "cursor" : { // only for getMore operations "cursorId" : <Long()>, "createdDate" : <ISODate()>, "lastAccessDate" : <ISODate()>, "nDocsReturned" : <Long()>, "nBatchesReturned" : <Long()>, "noCursorTimeout" : <boolean>, "tailable" : <boolean>, "awaitData" : <boolean>, "originatingCommand" : <document>, "planSummary" : <string>, "operationUsingCursorId" : <Long()> }, "msg": <string>, "progress" : { "done" : <number>, "total" : <number> }, "killPending" : <boolean>, "numYields" : <number>, "dataThroughputLastSecond" : <number>, "dataThroughputAverage" : <number>, "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" : Long(0), "w" : Long(0), "R" : Long(0), "W" : Long(0) }, "deadlockCount" : { "r" : Long(0), "w" : Long(0), "R" : Long(0), "W" : Long(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" : <Long()>, "autocommit" : <boolean>, "readConcern" : { "level" : <string> } }, "readTimestamp" : <Timestamp>, "startWallClockTime" : <string>, "timeOpenMicros" : <Long()>, "timeActiveMicros" : <Long()>, "timeInactiveMicros" : <Long()>, "expiryTime" : <string>, }, "active" : <boolean>, "currentOpTime" : <string>, "effectiveUsers" : [ { "user" : <string>, "db" : <string> } ], "opid" : <number>, "secs_running" : <Long()>, "microsecs_running" : <number>, "op" : <string>, "ns" : <string>, "command" : <document>, "originatingCommand" : <document>, "queryFramework" : <string>, "planSummary": <string>, "prepareReadConflicts" : <Long()>, "writeConflicts" : <Long()>, "cursor" : { // only for getMore operations "cursorId" : <Long()>, "createdDate" : <ISODate()>, "lastAccessDate" : <ISODate()>, "nDocsReturned" : <Long()>, "nBatchesReturned" : <Long()>, "noCursorTimeout" : <boolean>, "tailable" : <boolean>, "awaitData" : <boolean>, "originatingCommand" : <document>, "planSummary" : <string>, "operationUsingCursorId" : <Long()> }, "msg": <string>, "progress" : { "done" : <number>, "total" : <number> }, "killPending" : <boolean>, "numYields" : <number>, "dataThroughputLastSecond" : <number>, "dataThroughputAverage" : <number>, "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" : Long(0), "w" : Long(0), "R" : Long(0), "W" : Long(0) }, "deadlockCount" : { "r" : Long(0), "w" : Long(0), "R" : Long(0), "W" : Long(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" : <Long()>, "autocommit" : <boolean>, "readConcern" : { "level" : <string> } }, "readTimestamp" : <Timestamp>, "startWallClockTime" : <string>, "timeOpenMicros" : <Long()>, "timeActiveMicros" : <Long()>, "timeInactiveMicros" : <Long()>, "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" : <Long()>, "microsecs_running" : <number>, "op" : <string>, "ns" : <string>, "command" : <document>, "configTime" : <Timestamp>, // Starting in 5.0 "topologyTime" : <Timestamp>, // Starting in 5.0 "queryFramework" : <string>, // Starting in 6.2 "planSummary": <string>, "prepareReadConflicts" : <Long()>, "writeConflicts" : <Long()>, "cursor" : { // only for getMore operations "cursorId" : <Long()>, "createdDate" : <ISODate()>, "lastAccessDate" : <ISODate()>, "nDocsReturned" : <Long()>, "nBatchesReturned" : <Long()>, "noCursorTimeout" : <boolean>, "tailable" : <boolean>, "awaitData" : <boolean>, "originatingCommand" : <document>, "planSummary" : <string>, "operationUsingCursorId" : <Long()> }, "msg": <string>, "progress" : { "done" : <number>, "total" : <number> }, "killPending" : <boolean>, "numYields" : <number>, "dataThroughputLastSecond" : <number>, "dataThroughputAverage" : <number>, "locks" : { "ParallelBatchWriterMode" : <string>, "ReplicationStateTransition" : <string>, "Global" : <string>, "Database" : <string>, "Collection" : <string>, "Metadata" : <string>, "DDLDatabase" : <string>, "DDLCollection" : <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" : Long(0), "w" : Long(0), "R" : Long(0), "W" : Long(0) }, "deadlockCount" : { "r" : Long(0), "w" : Long(0), "R" : Long(0), "W" : Long(0) } }, "ReplicationStateTransition" : { ... }, "Global" : { ... }, "Database" : { ... }, ... } }, ... ], "ok": <num>, "operationTime": <timestamp>, "$clusterTime": <document> }
Specific Output Examples
These output samples illustrate currentOp output for particular
operations. The fields that make up the actual output vary depending on
the server's role.
Resharding Output Example
{ shard: '<string>', totalCopyTimeElapsedSecs: Long('<count>'), totalApplyTimeElapsedSecs: Long('<count>'), totalCriticalSectionTimeElapsedSecs: Long('<count>'), totalIndexBuildTimeElapsedSecs: Long('<count>'), indexesToBuild: Long('<count>'), indexesBuilt: Long('<count>'), oplogEntriesFetched: Long('<count>'), oplogEntriesApplied: Long('<count>'), insertsApplied: Long('<count>'), updatesApplied: Long('<count>'), deletesApplied: Long('<count>'), type: 'op', desc: 'ReshardingMetrics{Donor|Recipient|Coordinator}Service <reshardingUUID>', op: 'command', ns: '<database>.<collection>', originatingCommand: { reshardCollection: '<database>.<collection>', key: '<shardkey>', unique:'<boolean>', collation: { locale: 'simple' } }, totalOperationTimeElapsedSecs: Long('<count>'), recipientState: '<service state>', remainingOperationTimeEstimatedSecs: Long('<count>'), approxDocumentsToCopy: Long('<count>'), approxBytesToCopy: Long('<count>'), bytesCopied: Long('<count>'), countWritesToStashCollections: Long('<count>'), documentsCopied: Long('<count>'), provenance: 'reshardCollection' }
Output Fields
currentOp.typeThe type of operation. Values are either:
opidleSessionidleCursor
If the
currentOp.typeisop,currentOp.opprovides details on the specific operation.
currentOp.descA description of the client. This string includes the
connectionId.
currentOp.clientA string with information about where the operation originated.
For multi-document transactions,
clientstores information about the most recent client to run an operation inside the transaction.
currentOp.appNameThe identifier of the client application which ran the operation. Use the
appNameconnection string option to set a custom value for theappNamefield.
currentOp.clientMetadataAdditional information on the client.
For multi-document transactions,
clientstores information about the most recent client to run an operation inside the transaction.
currentOp.currentQueueNew in version 8.0.
The current queue of the operation.
currentOp.currentQueue.nameThe name of the current queue of the operation.
Note
If
currentQueueis present andnameisingress, the operation is waiting for ingress admission.
currentOp.queuesInformation about the current operation's
ingressandexecutionqueues.
currentOp.effectiveUsersAn array that contains a document for each user associated with the operation. Each user document contains the
username and the authenticationdb.
currentOp.runByAn array that contains a document for each user who is impersonating the
effectiveUser(s)for the operation. The runBy document contains theusername and the authenticationdb. In general, the runBy user is the__systemuser; e.g."runBy" : [ { "user" : "__system", "db" : "local" } ] Only available on sharded clusters
currentOp.transactionA document that contains multi-document transaction information.
Only present if the operation is part of a multi-document transaction.
currentOp.transaction.parametersA document that contains information on multi-document transaction.
Only present if the operation is part of a multi-document transaction.
currentOp.transaction.parameters.txnNumberThe transaction number.
Only present if the operation is part of a multi-document transaction.
currentOp.transaction.parameters.autocommitA 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.readConcernThe 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.readTimestampThe 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.startWallClockTimeThe date and time (with time zone) of the transaction start.
Only present if the operation is part of a multi-document transaction.
currentOp.transaction.timeOpenMicrosThe duration of the transaction in microseconds.
The
timeActiveMicrosvalue added to thetimeInactiveMicrosshould equal thetimeOpenMicros.Only present if the operation is part of a multi-document transaction.
currentOp.transaction.timeActiveMicrosThe total amount of time that the transaction has been active; i.e. when the transaction had operations running.
The
timeActiveMicrosvalue added to thetimeInactiveMicrosshould equal thetimeOpenMicros.Only present if the operation is part of a multi-document transaction.
currentOp.transaction.timeInactiveMicrosThe total amount of time that the transaction has been inactive; i.e. when the transaction had no operations running.
The
timeInactiveMicrosvalue added to thetimeActiveMicrosshould equal thetimeOpenMicros.Only present if the operation is part of a multi-document transaction.
currentOp.transaction.expiryTimeThe date and time (with time zone) when the transaction will time out and abort.
The
currentOp.transaction.expiryTimeequals thecurrentOp.transaction.startWallClockTime+ thetransactionLifetimeLimitSeconds.For more information, see Runtime Limit for transactions.
Only present if the operation is part of a multi-document transaction.
currentOp.twoPhaseCommitCoordinatorInformation 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 amongosor 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.typeisopandcurrentOp.descis"TransactionCoordinator") spawned by the transaction coordinator.
currentOp.twoPhaseCommitCoordinator.lsidThe session identifier for the multi-shard transaction.
The combination of the
lsidandtxnNumberidentifies the transaction.Available for both the commit coordination metrics and for specific coordination operation.
currentOp.twoPhaseCommitCoordinator.txnNumberThe transaction number for the multi-shard transaction.
The combination of the
txnNumberandlsididentifies the transaction.Available for both the commit coordination metrics and for specific coordination operation.
currentOp.twoPhaseCommitCoordinator.actionThe specific commit coordination operation spawned by the transaction coordinator:
"sendingPrepare""sendingCommit""sendingAbort""writingParticipantList""writingDecision""deletingCoordinatorDoc"
Only available for specific coordination operation.
currentOp.twoPhaseCommitCoordinator.startTimeThe start date and time of the
action.Only available for specific coordination operation.
currentOp.twoPhaseCommitCoordinator.numParticipantsNumber of shards participating in this commit.
Only available for the commit coordination metrics.
currentOp.twoPhaseCommitCoordinator.stateThe current step/state of the commit coordination process.
Step/stageDescriptioninactiveNot actively part of a commit.
writingParticipantListWriting a local record of the list of shards that are part of this multi-shard transaction.
waitingForVotesWaiting for the participants to respond with vote to commit or abort.
writingDecisionWriting a local record of the coordinator's decision to commit or abort based on votes.
waitingForDecisionAckWaiting for participants to acknowledge the coordinator's decision to commit or abort.
deletingCoordinatorDocDeleting the local record of commit decision.
Only available for the commit coordination metrics.
currentOp.twoPhaseCommitCoordinator.commitStartTimeThe date and time when the commit started.
Only available for the commit coordination metrics.
currentOp.twoPhaseCommitCoordinator.hasRecoveredFromFailoverA boolean that indicates whether the commit coordination was restarted due to failover on the shard that is coordinating the commit.
If
hasRecoveredFromFailoveris true, then the times specified incurrentOp.twoPhaseCommitCoordinator.stepDurationsmay not be accurate for all steps.Only available for the commit coordination metrics.
currentOp.twoPhaseCommitCoordinator.stepDurationsA document that contains the duration, in microseconds, of the commit coordination
steps/statecompleted or in progress:"stepDurations" : { "writingParticipantListMicros" : Long(17801), "totalCommitDurationMicros" : Long(42488463), "waitingForVotesMicros" : Long(30378502), "writingDecisionMicros" : Long(15015), "waitingForDecisionAcksMicros" : Long(12077145), "deletingCoordinatorDocMicros" : Long(6009) }, If
currentOp.twoPhaseCommitCoordinator.hasRecoveredFromFailoveris true, then the times specified instepDurationsmay not be accurate for all steps.For a coordinator in an
inactivestate, the document is empty:"stepDurations" : { } Only available for the commit coordination metrics.
currentOp.twoPhaseCommitCoordinator.decisionA document that contains the commit/abort decision, for example:
For a commit 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.deadlineThe date and time by which the commit must finish.
Only available for the commit coordination metrics.
currentOp.opidThe identifier for the operation. You can pass this value to
db.killOp()inmongoshto 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.activeA boolean value specifying whether the operation has started. Value is
trueif the operation has started orfalseif 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_runningThe 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
activeistrue.
currentOp.microsecs_runningThe 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
activeistrue.
currentOp.opA string that identifies the specific operation type. Only present if
currentOp.typeisop.The possible values are:
"none""update""insert""query""command""getmore""remove""killcursors"
"query"operations include read operations."command"operations include most commands such as thecreateIndexesandfindAndModify.
currentOp.nsThe namespace the operation targets. A namespace consists of the database name and the collection name concatenated with a dot (
.); that is,"<database>.<collection>".
currentOp.commandA document containing the full command object associated with this operation.
For example, the following output contains the command object for a
findoperation on a collection nameditemsin a database namedtest:"command" : { "find" : "items", "filter" : { "sku" : 1403978 }, ... "$db" : "test" } The following example output contains the command object for a
getMoreoperation generated by a command with cursor ID19234103609on a collection nameditemsin a database namedtest:"command" : { "getMore" : Long("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
$truncatedfield contains a string summary of the document excluding the document'scommentfield 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
commentfield is present if a comment was passed to the operation. A comment may be attached to any database command.
currentOp.planSummarySpecifies whether the cursor uses a collection scan (
COLLSCAN) or an index scan (IXSCAN { ... }).The
IXSCANalso includes the specification document of the index used.
currentOp.prepareReadConflictsThe 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.
currentOp.writeConflictsThe number of times the current operation conflicted with another write operation on the same document.
currentOp.cursorA document that contains the cursor information for
getmoreoperations; i.e. whereopisgetmore.If reporting on a
getmoreoperation before thegetmorehas accessed its cursor information, thecursorfield is not available.currentOp.cursor.noCursorTimeoutThe flag that indicates that the cursor will not timeout when idle; i.e. if the cursor has the
noTimeoutoption set.If true, the cursor does not time out when idle.
If false, the cursor times out when idle.
currentOp.cursor.tailableThe 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.awaitDataThe flag that indicates whether the tailable cursor should temporarily block a
getMorecommand on the cursor while waiting for new data rather than returning no data.For non-tailable cursors, the value is always false.
currentOp.cursor.originatingCommandThe
originatingCommandfield contains the full command object (e.g.findoraggregate) which originally created the cursor.
currentOp.locksThe
locksdocument reports the type and mode of locks the operation currently holds. The possible lock types are as follows:Lock TypeDescriptionParallelBatchWriterModeRepresents a lock for parallel batch writer mode.
In earlier versions, PBWM information was reported as part of the
Globallock information.ReplicationStateTransitionRepresents lock taken for replica set member state transitions.
GlobalRepresents global lock.
DatabaseRepresents database lock.
CollectionRepresents collection lock.
MutexRepresents mutex.
MetadataRepresents metadata lock.
DDLDatabaseRepresents a DDL database lock.
New in version 7.1.
DDLCollectionRepresents a DDL collection lock.
New in version 7.1.
oplogRepresents lock on the oplog.
The possible modes are as follows:
Lock ModeDescriptionRRepresents Shared (S) lock.
WRepresents Exclusive (X) lock.
rRepresents Intent Shared (IS) lock.
wRepresents Intent Exclusive (IX) lock.
currentOp.admissionPriorityFor internal use. The value is the priority an operation has when it tries to acquire a ticket in order to perform a storage engine action.
Possible values are: "low", "normal", and "immediate". Only operations with a "low" value are reported.
Sample
currentOpoutput:{ type: 'op', host: 'ip-10-122-5-147:27017', desc: 'JournalFlusher', active: true, currentOpTime: '2022-10-11T12:45:52.053+00:00', opid: 201, op: 'none', ns: '', command: {}, numYields: 0, admissionPriority: 'low', locks: {}, waitingForLock: false, lockStats: {}, waitingForFlowControl: false, flowControlStats: {} } The
admissionPriorityvalue is also reported in the slow log.New in version 6.3.
currentOp.waitingForLockReturns a boolean value.
waitingForLockistrueif the operation is waiting for a lock andfalseif the operation has the required lock.
currentOp.msgThe
msgprovides 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.progressReports on the progress of mapReduce or indexing operations. The
progressfields corresponds to the completion percentage in themsgfield. Theprogressspecifies the following information:
currentOp.killPendingReturns
trueif the operation is currently flagged for termination. When the operation encounters its next safe termination point, the operation will terminate.
currentOp.numYieldsnumYieldsis 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.dataThroughputLastSecondAmount of data (in MiB) processed by the
validateoperation in the last second. Only available for avalidateoperation 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.dataThroughputAverageThe average amount of data (in MiB) processed by the
validateoperation. Only available for avalidateoperation 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.fsyncLockSpecifies if database is currently locked for
fsync write/snapshot.Only appears if locked; i.e. if
fsyncLockistrue.
currentOp.infoInformation regarding how to unlock database from
db.fsyncLock(). Only appears iffsyncLockistrue.
currentOp.lockStatsFor each lock type and mode (see
currentOp.locksfor descriptions of lock types and modes), returns the following information:currentOp.lockStats.acquireCountNumber of times the operation acquired the lock in the specified mode.
currentOp.lockStats.acquireWaitCountNumber of times the operation had to wait for the
acquireCountlock acquisitions because the locks were held in a conflicting mode.acquireWaitCountis less than or equal toacquireCount.
currentOp.lockStats.timeAcquiringMicrosCumulative time in microseconds that the operation had to wait to acquire the locks.
timeAcquiringMicrosdivided byacquireWaitCountgives an approximate average wait time for the particular lock mode.
currentOp.waitingForFlowControlA boolean that indicates if the operation is in the process of waiting for flow control.
currentOp.flowControlStatsThe flow control statistics for this operation.
currentOp.totalOperationTimeElapsedSecsThe 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.
Starting in MongoDB 6.1, this metric is also available on the coordinator during resharding.
currentOp.updatesAppliedThe number of updates applied.
Only present on a recipient shard when a resharding operation is taking place.
New in version 6.1.
currentOp.remainingOperationTimeEstimatedSecsremainingOperationTimeEstimatedSecs: estimated time remaining in seconds for the current resharding operation. It is returned as-1when a new resharding operation starts.Starting in MongoDB 7.0,
remainingOperationTimeEstimatedSecsis also available on the coordinator during a resharding operation.remainingOperationTimeEstimatedSecsis 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.allShardsLowestRemainingOperationTimeEstimatedSecsCalculated across all shards, the lowest estimate of the number of seconds remaining.
Only present on a coordinator when a resharding operation is taking place.
New in version 6.1.
currentOp.allShardsHighestRemainingOperationTimeEstimatedSecsCalculated across all shards, the highest estimate of the number of seconds remaining.
Only present on a coordinator when a resharding operation is taking place.
New in version 6.1.
currentOp.approxDocumentsToCopyThe 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.documentsCopiedand$currentOp.bytesCopiedto end up exceeding$currentOp.approxDocumentsToCopyand$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.documentsCopiedThe 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.approxBytesToCopyThe 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.documentsCopiedand$currentOp.bytesCopiedto end up exceeding$currentOp.approxDocumentsToCopyand$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.bytesCopiedThe 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.countWritesToStashCollectionsThe number of writes to the recipient stash collections.
Only present on a recipient shard when a resharding operation is taking place.
New in version 6.1.
currentOp.countWritesDuringCriticalSectionThe number of writes attempted during the donor's critical section.
Only present on a donor shard when a resharding operation is taking place.
New in version 6.1.
currentOp.countReadsDuringCriticalSectionThe number of reads attempted during the donor's critical section.
Only present on a donor shard when a resharding operation is taking place.
New in version 6.1.
currentOp.deletesAppliedThe number of deletes applied to the temporary resharding collection. Each oplog entry that involves a delete increments the counter by 1.
Only present on a recipient shard when a resharding operation is taking place.
New in version 6.1.
currentOp.insertsAppliedThe number of inserts applied to the temporary resharding collection. Each oplog entry that involves an insert increments the counter by 1.
Only present on a recipient shard when a resharding operation is taking place.
New in version 6.1.
currentOp.totalCopyTimeElapsedSecsThe 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.
Starting in MongoDB 6.1, this metric is also available on the coordinator during resharding.
currentOp.oplogEntriesFetchedThe 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.oplogEntriesAppliedThe 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.totalApplyTimeElapsedSecsThe 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.
Starting in MongoDB 6.1, this metric is also available on the coordinator during resharding.
currentOp.countWritesDuringCriticalSectionThe number of writes performed 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.totalCriticalSectionTimeElapsedSecsThe 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.
Starting in MongoDB 6.1, this metric is also available on the coordinator during resharding.
currentOp.donorStateThe current state of a donor shard for the resharding operation. The state is set to
unusedwhen a new resharding operation starts.Only present on a donor shard when a resharding operation is taking place.
StateDescriptionunusedThe resharding operation is about to start or recovering from a primary failover.
preparing-to-donateThe donor shard is preparing to donate data to the recipient shards.
donating-initial-dataThe donor shard is donating data to the recipient shards.
donating-oplog-entriesThe donor shard is donating oplog entries to the recipient shards.
preparing-to-block-writesThe donor shard is about to prevent new incoming write operations to the collection that is being resharded.
errorAn error occurred during the resharding operation.
blocking-writesThe donor shard is preventing new incoming write operations and the donor shard has notified all recipient shards that new incoming writes are prevented.
doneThe donor shard has dropped the old sharded collection and the resharding operation is complete.
New in version 5.0.
currentOp.recipientStateThe current state of a recipient shard for a resharding operation. The state is set to
unusedwhen a new resharding operation starts.Only present on a donor shard when a resharding operation is taking place.
StateDescriptionunusedThe resharding operation is about to start or recovering from a primary failover.
awaiting-fetch-timestampThe recipient shard is waiting for the donor shards to be prepared to donate their data.
creating-collectionThe recipient shard is creating the new sharded collection.
cloningThe recipient shard is receiving data from the donor shards.
applyingThe recipient shard is applying oplog entries to modify its copy of the data based on the new incoming writes from donor shards.
errorAn error occurred during the resharding operation.
strict-consistencyThe recipient shard has all data changes stored in a temporary collection.
doneThe resharding operation is complete.
New in version 5.0.
currentOp.coordinatorStateThe 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
unusedwhen a new resharding operation starts.Only present on the coordinating config server.
StateDescriptionunusedThe resharding operation is about to start or recovering from a primary failover.
initializingThe resharding coordinator has inserted the coordinator document into
config.reshardingOperationsand has added thereshardingFieldsto theconfig.collectionsentry for the original collection.preparing-to-donateThe resharding coordinator
has created a
config.collectionsentry for the temporary resharding collection.has inserted entries into
config.chunksfor ranges based on the new shard key.has inserted entries into
config.tagsfor 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
minFetchTimestampand are ready to donate.cloningThe 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.
applyingThe 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-writesThe 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.
abortingAn unrecoverable error occurred during the resharding operation or the
abortReshardCollectioncommand (or thesh.abortReshardCollection()method) was run.committingThe resharding coordinator removes the
config.collectionsentry for the temporary resharding collection. The coordinator then adds therecipientFieldsto the source collection's entry.New in version 5.0.
currentOp.collUuidThe UUID of the sampled collection.
This field only appears on documents related to query sampling. For details, see Sampled Queries.
New in version 7.0.
currentOp.startTimeThe time at which query sampling began.
This field only appears on documents related to query sampling. For details, see Sampled Queries.
New in version 7.0.
currentOp.samplesPerSecondThe maximum number of queries to sample per second.
On a sharded cluster, this is reported on
mongosinstead ofmongod. On a replica set, this is reported onmongod.This field only appears on documents related to query sampling. For details, see Sampled Queries.
New in version 7.0.
currentOp.sampledReadsCountThe number of sampled read queries.
This field only appears on documents related to query sampling. For details, see Sampled Queries.
New in version 7.0.
currentOp.sampledWritesCountThe number of sampled write queries.
This field only appears on documents related to query sampling. For details, see Sampled Queries.
New in version 7.0.
currentOp.sampledReadsBytesThe size of the sampled read queries, in bytes.
On a replica set, this is reported on every
mongod.On a sharded cluster, this only reported on
mongodwith--shardsvr.This field only appears on documents related to query sampling. For details, see Sampled Queries.
New in version 7.0.
currentOp.sampledWritesBytesThe size of the sampled write queries, in bytes.
On a replica set, this is reported on every
mongod.On a sharded cluster, this only reported on
mongodwith--shardsvr.This field only appears on documents related to query sampling. For details, see Sampled Queries.
New in version 7.0.