mongo kill慢查詢

例1：查詢全部正在等待鎖的寫操做

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

例2：查詢全部操做db1而且執行時間已超過3s的請求

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

 

currentOp的過濾條件包括

請求操做類型，insert、update、delete…
請求對應的connectionId，threadId
請求是否正在等待鎖
請求執行時間
請求操做的DB或collection
請求query的內容
…

 

killOp

currentOp的輸出結果裏，每一個請求包含一個opid字段，有了opid，就能夠發送killOp來幹掉對應的請求。

db.killOp(opid)

 

客戶端到Monogd Server鏈接斷掉後，鏈接上執行的請求是否會當即結束？

好比你經過mongo shell，發送了一個createIndex的請求，給某個包含1000w個文檔的集合創建索引，這個請求會耗時好久，你想提早停止請求，Ctrl-C停掉了mongo shell，此時mongo shell到server的鏈接會關閉掉。

但後端createIndex的請求（MongoDB每一個鏈接的請求由一個對應的線程來處理）不會當即結束，而是會一直執行下去，直到createIndex結束，給客戶端發送應答時，發現鏈接已經關閉，而後線程才退出。

爲了讓createIndex早點結束，你就須要killOp來幫忙，經過currentOp找到craeteIndex請求的opid，而後發送killOp，createIndex會在下個『檢查點』就結束執行，整個線程退出。

發送killOp後，請求是否會當即結束？

killOp的實現原理以下

每一個鏈接對應的服務線程存儲了一個killPending的字段，當發送killOp時，會將該字段置1；請求在執行過程當中，能夠經過不斷的調用OperationContext::checkForInterrupt()來檢查killPending是否被設置，若是被設置，則線程退出。

一個請求要支持killOp，必須在請求的處理邏輯里加上checkForInterrupt()檢查點才行，不然即便發送了killOp，也只能等待請求徹底處理完畢線程纔會退出。

好比createIndex的處理邏輯裏包含了相似以下的代碼，在createIndex的循環過程當中，一旦killPending被置1了，createIndex的執行能夠在當前循環結束時退出。

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

因此發送killOp後，請求要執行到下一個『檢查點』線程纔會退出，MongoDB在不少可能耗時長的請求中，都加入了checkForInterrupt()檢查點，如建立索引，repair database，mapreduce、aggregation等。