2

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.

  • Ok, the query was tanking our database, so we just restarted the mongod service. Our other secondaries stepped up, which was good, but this is not the solution I was looking for. – LoveMeSomeCode Mar 28 '14 at 19:09
-1

From this: https://dba.stackexchange.com/questions/60029/how-do-i-safely-kill-long-running-operations-in-mongodb


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.

  • To prevent link-rot, please try to include the relevant information from any linked articles in your answer. – BE77Y Jun 17 '16 at 13:38
  • @BE77Y Thanks for the suggestion. Added! – ScionOfBytes Jun 20 '16 at 10:39
  • I'd say it's dangerous/counter-productive to automate killing of processes when you don't know what they're doing. There could be very legitimate processes taking a long time, such as a backup process collecting documents, or some custom housekeeping workflow. If this kill script is running, forgotten, it can make it very hard to troubleshoot why my special script suddenly dies for no apparent reason. – Nic Cottrell Apr 13 at 13:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.