currentOp() in MongoDBI have been working a while with customers, supporting both MongoDB and MySQL technologies. Most of the time when an issue arises, the customers working with MySQL collect most of the information happening in the DB server, including all the queries running that particular time, using “show full processlist;” This information would help us to look at the problem, like which queries are taking the time and where it was spending the time. 

But for MongoDB, most of the time we don’t receive this (in-progress operations) information. And we had to check with long queries logged into the MongoDB log file and, of course, it writes most of the things like planSummary (whether it used the index or not), documents/index scanned, time to complete, etc. It’s like doing a postmortem rather than checking the issue happening in real-time. Actually collecting the information about operations taking the time or finding a problematic query while the issue is happening could help you find the right one to kill (to release the pressure) or check the situation of the database. 

The in-progress operations in MongoDB can be checked via the database command currentOp(). The level of information can be controlled via the options passed through it. Most of the time, the output from it is not that interesting to check because it contains a lot of information, making it difficult to spot the ones we need. However, MongoDB knows this and has included many options to filter the operations using currentOp over multiple versions easily. Some of the information regarding this is mentioned in the below release notes:

https://docs.mongodb.com/manual/release-notes/3.6/#new-aggregation-stages 

https://docs.mongodb.com/manual/release-notes/4.0/#id26

https://docs.mongodb.com/manual/release-notes/4.2/#currentop 

In this blog, I will share some tricks to work with this command and fetch the operations that we need to check. This would help a person check the ongoing operations and if necessary, kill the problematic command – if they wish.

Introduction

The database command ` provides information about the ongoing/currently running operations in the database. It must be run against the admin database. On servers that run with authorization, you need the inprog privilege action to view operations for all users. This is included in the built-in clusterMonitor role.

Use Cases

The command to see all the active connections:

The user that has no inprog privilege can view its own operations, without this privilege, with the below command:

To see the connections in the background, and idle connections, you can use either one of the below commands:

As I said before, you can use filters here to check the operations you need, like a command running for more than a few seconds, waiting for a lock, active/inactive connections, running on a particular namespace, etc. Let’s see some examples from my test environment.

The below command provides information about all active connections. 

Some of the important parameters that we may need to focus on from the output are as follows. I provide this information here as we will use these parameters to filter for the operations that we need.

PARAMETERDESCRIPTION
hostThe host that the operation is running
opidThe operation id (it is used to kill that operation) 
activeThe connection’s status. True if it is running and false if it is idle
clientHost/IP information about where the operation originated
clientMetadataProvides more information about client connection
shardWhich shard is connected if it is sharded cluster environment
appNameInformation about the type of client
currentOpTimeStart time of the operation
nsNamespace (details about the DB and collection)
commandA document with the full command object associated with the operation
secs_running / microsecs_runningHow many seconds/microseconds that the particular operation is running
opOperation type like insert, update, find, delete etc
planSummaryWhether the command uses the index IXSCAN or collection scan COLLSCAN (disk read)
cursorCursor information for getmore operations
locksType and mode of the lock. See here for more details
waitingForLockTrue if the operation waiting for a lock, false if it has required lock
msgA message that describes the status and progress of the operation
killPendingWhether the operation is currently flagged for termination
numYieldsIs a counter that reports the number of times the operation has yielded to allow other operation

The raw currentOp output can be processed by the javascript forEach function method in the mongo shell, so we can use it to do many operations. For example, I want to take counts of the output or number of active connections. Then I can use the below one:

To find the number of active and inactive connections:

To find the operations running (importing job) more than 1000 microseconds (for seconds, use secs_running) and with a specific namespace vinodh.testColl:

But this command can be easily written without forEach as follows directly as well:

The operations waiting for the lock on a specific namespace (ns) / operation (op) can be filtered as follows, and you can alter the parameters to filter as you wish:

Aggregate – currentOp():

Starting with MongoDB 3.6, currentOp method is supported in aggregation. So checking the currentOp is even easier with this method. Also, the aggregation pipeline doesn’t have a 16MB result size limit as well. The usage is:

Note:

Options/Features added, version-wise, to currentOp()

  • allUsers, idleConnections – available from 3.6,
  • idleCursors – available from 4.2
  • idleSessions, localOps – available from 4.0

Let’s see an example of the same. Count all connections including idle connections with shard02:

Now using the same import job, finding the operation as follows:

To reduce the output and project only some fields in the output:

To see the output in fantasy mode, used to be pretty 🙂

I hope now you will have some idea on using currentOp() to check the ongoing operations. 

Let’s imagine you want to kill an operation running for a long time. From the same currentOp document you identified it with, you can take the opid and kill it using killOp() method. In the example below, I used the sharded environment and so the opid is in a “shard_no:opid” format. See here for more details.

Conclusion

So the next time when you want to check the ongoing operations, you can use these techniques for filtering operations waiting for a lock, running on a namespace, running more than a specified time, specific operation or specific shard, etc. Also, comment here if you have any other ideas on this topic. I am happy to learn/see that as well.

Percona Distribution for MongoDB is the only truly open-source solution powerful enough for enterprise applications.

It’s free to use, so try it today!

1 Comment
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Kay Agahd

Vinodh,

you may simplify this task by using the mongodb-slow-operations-profiler tool, open-sourced on github. It is able to show you in a tabular representation all current running operations of one or multiple databases with just 2 clicks. The table is filterable and columns are sortable, so you can easily see the longest running queries, of the namespace you’re interested in, first.
I wrote a blog post about the tool and specifically also about its current-operations-feature: https://medium.com/idealo-tech-blog/practical-guide-to-analyze-slow-mongodb-operations-9363035b01fb#15e2

Have a look, be inspired and simplify your daily work 🙂

Best regards!

0