Amazon DocumentDB 中的垃圾回收 - Amazon DocumentDB
了解 Amazon DocumentDB 中的垃圾回收垃圾回收程序監控垃圾回收collStats 輸出範例常見問答集

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

Amazon DocumentDB 中的垃圾回收

Amazon DocumentDB 實作多版本並行控制 (MVCC) 資料庫架構，為每個更新操作建立新的文件和索引項目版本。此架構允許讀取查詢使用版本控制的文件，而不進行鎖定，以提供讀取隔離。

了解 Amazon DocumentDB 中的垃圾回收

垃圾回收 (GC) 是一種自動化背景程序，可在 Amazon DocumentDB 中維持最佳的系統效能和可用性。與覆寫資料的傳統資料庫不同，Amazon DocumentDB 的 MVCC 架構會在每次更新操作時建立新的文件版本和索引項目。每個產生新文件版本的寫入操作都會從有限計數器耗用唯一的 MVCC ID，因此需要有效率的清除。隨著時間的推移，這些舊版本會累積並必須清除，以防止效能降低。

垃圾回收的函數

垃圾收集器提供三個基本函數：

  • 回收儲存空間 — 它移除作用中查詢不再需要的過時文件和索引版本，為未來的寫入操作釋放空間。

  • 防止 MVCC ID 溢位 — 透過管理 MVCC ID 的有限計數器來防止 MVCC IDs 溢位。如果沒有此管理，計數器最終會達到其限制，強制資料庫進入暫時唯讀模式，直到 IDs回收為止。

  • 維持查詢效能 — 它透過消除會累積和減慢查詢處理速度的無效文件版本，來維持最佳的查詢效能。

垃圾回收程序

GC 程序會依集合操作，並可在不同的集合上同時執行多個程序。程序包含四個循序階段：

  1. 識別 — 系統會識別作用中交易或查詢不再參考的文件和索引版本。

  2. 記憶體載入 — 如果舊文件和索引項目不存在，則會載入記憶體。

  3. 刪除 — 永久刪除過時的版本以回收儲存空間。

  4. MVCC ID 回收 — 系統會從已刪除的版本回收 MVCC IDs 以進行新操作。

當垃圾收集完成處理舊文件版本時，它會從系統中移除最舊的 MVCC IDs。此清除對於透過回收 MVCC ID 來防止 MVCC IDs 溢位至關重要，使其可用於整個叢集的新寫入操作。如果沒有此回收程序，系統最終會耗盡其有限的 MVCC ID 計數器，並進入唯讀狀態。

垃圾回收排程

垃圾回收會定期在背景自動執行。時間和頻率會根據系統負載、可用資源、寫入磁碟區和 MVCC ID 耗用量層級動態調整。在高寫入活動期間，GC 程序會更頻繁地執行，以管理增加的文件版本數量。

監控垃圾回收

叢集層級指標

AvailableMVCCIds

  • 位置 — Amazon CloudWatch

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

  • 建議 — 當值低於 13 億時設定警示。此提早警告可讓您採取稍後討論的建議步驟。

LongestRunningGCProcess

  • 位置 — Amazon CloudWatch

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

  • 建議 —

集合層級指標

MVCCIDStats: MvccIdAgeScale

  • 位置 — 資料庫 collStats 命令

  • 描述 — 以 0 到 1 的規模測量 MVCC ID 存留期，其中 1 表示叢集進入唯讀狀態之前的最大存留期。同時使用此指標AvailableMVCCIds來識別包含正在使叢集老化之最舊 MVCC IDs集合。

  • 建議 — 將每個集合的值保持在 0.3 以下。

GCRuntimeStats

  • 位置 — 資料庫 collStats 命令

  • 描述 — 提供垃圾收集指標的兩個月歷史記錄，包括總執行次數、平均持續時間和最長持續時間。僅包含持續超過五分鐘的垃圾回收操作，以確保有意義的統計資料。

UnusedStorageSize （集合層級）

  • 位置 — 資料庫 collStats 命令

  • 描述 — 根據取樣的統計資料，估計集合中未使用的儲存空間。它包含已刪除文件和空白區段的空間。

索引層級指標

UnusedStorageSize （索引層級）

  • Location — 資料庫 indexStats 命令

  • 描述 — 根據取樣的統計資料，估計索引中未使用的儲存空間。它包含來自過時索引項目和空區段的空間。

  • 建議 — 使用 reIndex命令來重建索引，無需停機時間並回收未使用的空間。如需詳細資訊，請參閱管理索引。

collStats 輸出範例

{
    "ns": "xid_consumption_test_db.xid_test_collection",
    "MVCCIdStats": {
        "MVCCIdScale": 0.03
    },
    "gcRuntimeStats": {
        "numRuns": 1,
        "historicalAvgRuntime": 3295,
        "historicalMaxRuntime": 3295,
        "lastRuntime": 3295,
        "lastRuntimeStart": ISODate("2025-06-24T08:47:14Z")
    },
    "collScans": 14,
    "count": 30000000,
    "size": 1320000000,
    "avgObjSize": 44,
    "storageSize": 6461497344,
    "capped": false,
    "nindexes": 2,
    "totalIndexSize": 9649553408,
    "indexSizes": {
        "_id_": 1910661120,
        "c_1": 7738892288
    },
    "unusedStorageSize": {
        "unusedBytes": 4201881600,
        "unusedPercent": 65.05
    },
    "cacheStats": {
        "collBlksHit": 171659016,
        "collBlksRead": 754061,
        "collHitRatio": 99.5627,
        "idxBlksHit": 692563636,
        "idxBlksRead": 1177921,
        "idxHitRatio": 99.8303
    },
    "idxScans": 41823984,
    "opCounter": {
        "numDocsIns": 0,
        "numDocsUpd": 20911992,
        "numDocsDel": 0
    },
    "lastReset": "2025-06-24 05:57:08.219711+00",
    "ok": 1,
    "operationTime": Timestamp(1750968826, 1)
}

常見問答集

如何識別垃圾回收是否無法有效運作？

監控這些警告訊號，指出垃圾回收效率不佳：

  • 集合膨脹過多 - 在大量寫入或大量刪除期間穩定增加UnusedStorageSize指標，尤其是使用大型索引時

  • 查詢延遲降低 — 由於累積的無效文件而增加的查詢延遲

  • 延長 GC 持續時間 — 中的垃圾回收操作耗時超過歷史平均值 GCRuntimeStats

  • 提升 GC 處理 — 高LongestRunningGCProcess表示垃圾收集器無法跟上系統需求

垃圾回收是否會影響我的資料庫效能？

在正常情況下，垃圾回收對效能的影響最小。不過，當垃圾回收落後時，您可能會遇到：

  • 從累積的無效文件增加儲存成本。

  • 由於索引項目過時，查詢效能變慢。

  • 如果 MVCC IDs，則為暫時唯讀模式。

  • 密集收集執行期間較高的資源用量，特別是在較小的執行個體上。

我可以手動觸發垃圾回收嗎？

否，Amazon DocumentDB 中的垃圾回收無法手動觸發。系統會自動管理垃圾回收，做為其內部維護操作的一部分。

我應該將哪些警示設定為操作最佳實務？

我們建議在叢集和集合層級設定監控，以確保 Amazon DocumentDB 系統的最佳效能。

用於叢集層級監控

首先，為閾值為 13 億的AvailableMVCCId指標建立 CloudWatch 警示。這可讓您有足夠的時間在指標達到零之前採取動作，此時您的叢集將進入唯讀模式。請記住，此指標可能會根據您的特定使用模式而波動。有些客戶看到它低於 13 億，然後隨著垃圾回收完成其工作而復原超過 15 億。

也請務必透過 CloudWatch 監控LongestRunningGCProcess指標。此指標與 GCRuntimeStats可協助您了解廢棄項目收集在系統中的效率。

用於集合層級監控

專注於兩個關鍵指標。首先，我們建議觀看每個集合MvccIdAgeScale的值。增加值表示 MVCC IDs 正在老化，可能需要注意。其次，監控 GCRuntimeStats 以識別任何需要異常長時間或持續數天的垃圾收集程序。具有頻繁寫入操作的集合需要額外注意，因為它們為垃圾收集器產生更多工作。對於具有繁重寫入活動的集合，我們建議您更頻繁地檢查這些指標，以確保垃圾收集與您的工作負載保持一致。

請注意，這些監控建議做為起點。當您更熟悉系統的行為時，建議您調整這些閾值，以更符合您的特定使用模式和需求。

如果我的 AvailableMVCCId 低於 13 億，該怎麼辦？

如果您的AvailableMVCCId指標低於 13 億，建議您立即採取行動，以防止您的叢集進入唯讀模式。我們建議您先擴展執行個體大小，為垃圾收集器提供更多運算資源。這可讓您的應用程式繼續正常操作，同時為垃圾收集器提供追上所需的額外能力。

如果單獨擴展無法改善情況，建議您考慮減少寫入操作。使用 MvccIdAgeScale 指標來識別哪些特定集合包含需要注意的較舊 MVCC IDs。識別這些集合之後，您可能需要暫時減少這些集合的寫入操作，以允許垃圾收集追上進度。在復原期間，我們建議您密切監控 AvailableMVCCId 指標，以確保您的動作具有所需的效果。一旦AvailableMVCCId值回到 15 億或更高，您的叢集就會被視為正常運作。

請記住，這些步驟是預防措施，可協助您的系統在達到嚴重狀態之前復原。看到指標降到 13 億以下之後，您採取動作的速度越快，就越有可能避免對寫入操作造成任何影響。