How to find/kill long running mongo scripts – A server stack is the collection of software that forms the operational infrastructure on a given machine. In a computing context, a stack is an ordered pile. A server stack is one type of solution stack — an ordered selection of software that makes it possible to complete a particular task. Like in this post about How to find/kill long running mongo scripts was one problem in server stack that need for a solution. Below are some tips in manage your linux server when you find problem about linux, mongodb, , , .
I think I have a long running mongo script tanking my database, but I’m not sure.
I was connected to the linux server via SSH and I ran the script like so:
mongo my_database my_script.js
It started chugging away, but it was taking too long, so I hit Ctrl-C
and dropped back to the shell. I assumed the script was killed off, but now I’m seeing queries that it contained still running on the database.
How do I get a list of scripts the database is currently running and kill them?
I know about db.currentOp
and db.killOp
, but the actual queries themselves are quick, I need to kill the script that’s running them in a loop.
This can be a little tricky, but the fact that the MongoDB shell is basically a Javascript interpreter gives us decent options in terms of filtering. Here is the function I use to accomplish this:
// kills long running ops in MongoDB (taking seconds as an arg to define "long")
// attempts to be a bit safer than killing all by excluding replication related operations
// and only targeting queries as opposed to commands etc.
killLongRunningOps = function(maxSecsRunning) {
currOp = db.currentOp();
for (oper in currOp.inprog) {
op = currOp.inprog[oper-0];
if (op.secs_running > maxSecsRunning && op.op == "query" && !op.ns.startsWith("local")) {
print("Killing opId: " + op.opid
+ " running over for secs: "
+ op.secs_running);
db.killOp(op.opid);
}
}
};
This will only kill queries above the maxSecsRunning threshold and will not touch anything running against the local database, which is where the oplog lives (and hence is the database that is involved in the long running replication ops. It is relatively easy to add criteria to the inner if conditional to more precisely target operations as needed based on specific needs.
The code is also available as a gist (where I will remember to update it on an ongoing basis).
This will help you target specific operations and terminate the same.