Shulou(Shulou.com)05/31 Report--

This article is about how to use killOp to kill Long Running Operation in Mongo. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

Detailed explanation:

Detailed explanation of currentOp ()

Gechongrepl:PRIMARY > db.currentOp ()

{

"inprog": [

{

"opid": 6222

"active": true

"secs_running": 3

"microsecs_running": NumberLong (3662328)

"op": "getmore"

"ns": "local.oplog.rs"

"query": {

}

"client": "192.168.91.132purl 45745"

"desc": "conn5"

"threadId": "0x7f1370cb4700"

"connectionId": 5

"waitingForLock": false

"numYields": 0

"lockStats": {

"timeLockedMicros": {

"r": NumberLong

"w": NumberLong (0)

}

"timeAcquiringMicros": {

"r": NumberLong (16)

"w": NumberLong (0)

}

}

}

]

}

"opid": 6222 # process number

"active": whether true,# is active

"secs_running": how many seconds did the # operation run?

"microsecs_running": NumberLong (3662328)

"op": "getmore", # operation type, including (insert/query/update/remove/getmore/command)

"ns": "local.oplog.rs", # namespace

"query": {}, # if op is a query operation, the query content will be displayed here; it is also said that specific operation statements are displayed here.

"client": "192.168.91.132 45745", # client information of the connection

"desc": "conn5", # connection information of the database

"threadId": "0x7f1370cb4700", # thread ID

"connectionId": 5Jing # database connection ID

"waitingForLock": whether false,# waits to acquire the lock

"numYields": 0

"lockStats": {

"timeLockedMicros": {# the lock time held in microseconds

"r": NumberLong (141), # Global read lock for the entire MongoDB instance

"w": NumberLong (0)}, # Global write lock for the entire MongoDB instance

"timeAcquiringMicros": {# the microsecond waiting time to acquire the lock

"r": NumberLong (16), # Global read lock for the entire MongoDB instance

"w": NumberLong (0)} # Global write lock for the entire MongoDB instance

MongoDB provides killOp requests to kill long-running requests. KillOp usually needs to be used in combination with currentOp; first query the requested opid according to currentOp, and then send the killOp request based on opid.

CurrentOp

For the use of currentOp, refer to the official documentation

CurrentOp lists all the requests that are being executed on the backend Mongod and can also filter based on query criteria such as the type of request, whether the request is waiting for a lock, and the DB or collection of the request operation.

Example 1: query all write operations waiting for a lock

Db.currentOp ({"waitingForLock": true, $or: [{"op": {"$in": ["insert", "update", "remove"]}}, {"query.findandmodify": {$exists: true}}]})

Example 2: query all requests that operate db1 and have been executed for more than 3 seconds

Db.currentOp ({"active": true, "secs_running": {"$gt": 3}, "ns": / ^ db1\. /})

The filtering criteria for currentOp include

Request operation type, insert, update, delete...

Request the corresponding connectionId,threadId

Whether the request is waiting for a lock

Request execution time

The DB or collection of the requested operation

Request the content of the query

...

KillOp

In the output of currentOp, each request contains an opid field. With opid, you can send killOp to kill the corresponding request.

Db.killOp (opid)

To understand the meaning of killOp, you need to figure out a few questions first.

Will the request executed on the connection end immediately after the client's connection to the Monogd Server is broken?

For example, if you send a createIndex request through mongo shell to index a collection of 1000w documents, the request will take a long time. If you want to abort the request in advance, Ctrl-C stops the mongo shell, and the connection from mongo shell to server is closed.

However, the request of the backend createIndex (the request for each connection of the MongoDB is processed by a corresponding thread) will not end immediately, but will be executed until the end of the createIndex, and when the reply is sent to the client, it is found that the connection has been closed and then the thread exits.

In order for createIndex to finish early, you need killOp to help you find the opid requested by craeteIndex through currentOp, and then send killOp,createIndex to finish execution at the next "checkpoint" and the entire thread exits.

Will the request end immediately after sending the killOp?

The implementation principle of killOp is as follows

The service thread corresponding to each connection stores a field of killPending, which is set to 1 when sending killOp. During the execution of the request, you can check whether the killPending is set by constantly calling OperationContext::checkForInterrupt (), and if so, the thread exits.

To support killOp, a request must add a checkForInterrupt () checkpoint to the processing logic of the request, otherwise, even if the killOp is sent, the thread will not exit until the request has been fully processed.

For example, the processing logic of createIndex contains code similar to the following. During the createIndex loop, once killPending is set to 1, the execution of createIndex can exit at the end of the current loop.

While (! createIndexFinished) {createIndexForOneElement (); checkForInterupt ();}

So after sending the killOp, the request will not exit until the next "checkpoint" thread. MongoDB adds checkForInterrupt () checkpoints to many requests that may take a long time, such as creating indexes, repair database,mapreduce, aggregation, and so on.

Thank you for reading! This is the end of the article on "how to use killOp to kill Long Running Operation in Mongo". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it for more people to see!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.