MongoDB管理：使用killOp干掉Long Running Operation

lyhabc

MongoDB提供了killOp請求，用于干掉運行時間很長的請求，killOp通常需要與currentOp組合起來使用；先根據(jù)currentOp查詢到請求的opid，然后根據(jù)opid發(fā)送killOp的請求。

currentOp

currentOp的使用，參考官方文檔

currentOp會將后端Mongod上正在執(zhí)行的請求都列出來，也可根據(jù)查詢條件（如請求類型，請求是否正在等待鎖，請求操作的DB或collection）來進行過濾。

例1：查詢所有正在等待鎖的寫操作

db.currentOp(
   {
     "waitingForLock" : true,
     $or: [
        { "op" : { "$in" : [ "insert", "update", "remove" ] } },
        { "query.findandmodify": { $exists: true } }
    ]
   }
)
例2：查詢所有操作db1并且執(zhí)行時間已超過3s的請求

db.currentOp(
   {
     "active" : true,
     "secs_running" : { "$gt" : 3 },
     "ns" : /^db1\./
   }
)
currentOp的過濾條件包括

請求操作類型，insert、update、delete…
請求對應的connectionId，threadId
請求是否正在等待鎖
請求執(zhí)行時間
請求操作的DB或collection
請求query的內(nèi)容
…
killOp

currentOp的輸出結果里，每個請求包含一個opid字段，有了opid，就可以發(fā)送killOp來干掉對應的請求。

db.killOp(opid)
要了解killOp的意義，需要先搞清楚幾個問題

客戶端到Monogd Server連接斷掉后，連接上執(zhí)行的請求是否會立即結束？

比如你通過mongo shell，發(fā)送了一個createIndex的請求，給某個包含1000w個文檔的集合建立索引，這個請求會耗時很久，你想提前中止請求，Ctrl-C停掉了mongo shell，此時mongo shell到server的連接會關閉掉。

但后端createIndex的請求（MongoDB每個連接的請求由一個對應的線程來處理）不會立即結束，而是會一直執(zhí)行下去，直到createIndex結束，給客戶端發(fā)送應答時，發(fā)現(xiàn)連接已經(jīng)關閉，然后線程才退出。

為了讓createIndex早點結束，你就需要killOp來幫忙，通過currentOp找到craeteIndex請求的opid，然后發(fā)送killOp，createIndex會在下個『檢查點』就結束執(zhí)行，整個線程退出。

發(fā)送killOp后，請求是否會立即結束？

killOp的實現(xiàn)原理如下

每個連接對應的服務線程存儲了一個killPending的字段，當發(fā)送killOp時，會將該字段置1；請求在執(zhí)行過程中，可以通過不斷的調(diào)用OperationContext::checkForInterrupt()來檢查killPending是否被設置，如果被設置，則線程退出。

一個請求要支持killOp，必須在請求的處理邏輯里加上checkForInterrupt()檢查點才行，否則即使發(fā)送了killOp，也只能等待請求完全處理完畢線程才會退出。

比如createIndex的處理邏輯里包含了類似如下的代碼，在createIndex的循環(huán)過程中，一旦killPending被置1了，createIndex的執(zhí)行可以在當前循環(huán)結束時退出。

while (!createIndexFinished) {
    createIndexForOneElement();
    checkForInterupt();
}
所以發(fā)送killOp后，請求要執(zhí)行到下一個『檢查點』線程才會退出，MongoDB在很多可能耗時長的請求中，都加入了checkForInterrupt()檢查點，如創(chuàng)建索引，repair database，mapreduce、aggregation等。