View a markdown version of this page

長時間執行的查詢 - Amazon DocumentDB
概觀對叢集的影響監控和偵測修復策略

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

長時間執行的查詢

概觀

長時間執行的查詢可能會層疊到整個叢集的效能問題。這些查詢可能會干擾 Amazon DocumentDB 的多版本並行控制 (MVCC) 垃圾收集程序，導致舊版本的文件累積，並降低叢集的效能。Amazon DocumentDB 實作 2 小時伺服器端逾時做為安全機制，以限制失控查詢無限期地耗用資源。

什麼是長時間執行的查詢：

  • 長時間執行的查詢 （通常 > 30 分鐘）

  • 開啟處於作用中狀態數小時的游標 （如果游標處於作用中狀態，則 2 小時逾時不適用）

對叢集的影響

長時間執行的查詢可能會干擾垃圾回收程序

  • 舊版本累積：垃圾收集器無法回收舊文件版本

  • 集合和索引膨脹：集合和索引項目會隨著時間累積、膨脹增加，並可能導致更多的儲存成本。

  • CPU 和記憶體壓力：由於舊文件版本、索引項目和交易 IDs 數量增加的處理效率不佳，CPU 和記憶體壓力會增加。

長時間執行的查詢 → 封鎖 GC → 儲存成長 → CPU 和記憶體壓力 → 更長的查詢

監控和偵測

1。若要尋找長時間執行的查詢，請使用 currentOp 命令。


// To find a query running for more than 30 mins
db.adminCommand({
    aggregate: 1,
    pipeline: [
        {$currentOp: {}},
        {$match: 
            {$or: 
                [{secs_running: {$gt: 1800}},
                 {WaitState: {$exists: true}}]}}],
    cursor: {}
});

2. 尋找作用中超過 30 分鐘的游標


// To find cursor which is running more than 30 mins
db.adminCommand({
    "currentOp": true,
    "active": true,
    "$all": true
}).inprog.filter(function(op) {
    return op.desc == "Cursor" && 
           op.secs_running > 1800 && 
           op.active == true;
}).sort((a, b) => b.microsecs_running - a.microsecs_running)

3. 透過 CloudWatch 監控垃圾收集器進度

LongestRunningGCProcess— 最長作用中垃圾回收程序的持續時間，以秒為單位。每分鐘更新一次，並僅追蹤作用中的操作，不包括在一分鐘時段內完成的程序。

AvailableMVCCIds - 顯示達到零之前可用的剩餘寫入操作數量的計數器。當此計數器達到零時，您的叢集會進入唯讀模式IDs直到 ID 回收和回收為止。計數器會隨著每次寫入操作而減少，並隨著垃圾回收回收舊的 MVCC IDs 而增加。

注意

較低的 MVCC IDs 和延長的垃圾收集期間並非僅歸因於長時間執行的查詢。資源限制執行個體上的寫入密集型工作負載也可能導致 MVCC ID 可用性降低和垃圾收集週期延長。

修復策略

  • 在應用程式中實作查詢逾時

  • 請勿讓游標存活更長的時間

  • 最佳化查詢以獲得更好的效能。

  • 偏好批次處理寫入操作