修訂清除 revision-cleanup

TarMK的持續性格式會隨著AEM 6.5而改變。這些變更不需要主動式移轉步驟。 現有存放庫會進行滾動式移轉，對使用者而言是透明的。 AEM 6.5 （或相關工具）首次存取存放庫時，就會起始移轉程式。

一旦開始移轉至AEM 6.5持續性格式，存放庫就無法恢復為先前的AEM 6.3持續性格式。

在AEM 6.3中，需要變更儲存格式，尤其是為了改善「線上修訂清除」的效能和功效。 這些變更無法回溯相容，且使用舊版Oak區段(AEM 6.2和舊版)建立的存放庫必須移轉。

變更儲存格式的其他優點：

• 更優異的擴充能力（最佳化的區段大小）。
• 更快 資料存放區記憶體回收.
• 為未來的增強功能做基礎工作。

離線修訂清除正在回收除了最新世代以外的所有專案，相較於線上修訂清除的最新兩代。 如果有新的存放庫，「線上修訂清除」在離線修訂清除後第一次執行時，將不會回收任何空間，因為沒有足夠老的層代可回收。

另請參閱的「離線修訂清除後執行線上修訂清除」一節。 本章.

因素包括：

• 存放庫大小
• 在系統上載入（每分鐘的要求數，特別是寫入作業）
• 活動模式（讀取與寫入）
• 硬體規格（CPU效能、記憶體、IOPS）

線上修訂清除期間會持續監視磁碟空間。 如果可用磁碟空間下降到臨界值以下，則會取消此程式。 關鍵值是存放庫目前磁碟空間的25%，且無法設定。

Adobe建議您讓磁碟的大小至少比最初估計的存放庫大小大兩到三倍。

在清理程式期間，會持續監視可用棧積空間。 如果可用棧積空間下降到關鍵值以下，則會取消此程式。 臨界值是透過org.apache.jackrabbit.oak.segment.SegmentNodeStoreService#MEMORY_THRESHOLD設定。 預設值為15%。

Recommendations的最小壓縮棧積大小建議與AEM記憶體大小建議沒有區分。 一般而言： 如果AEM執行個體的大小足以處理使用案例及其上的預期裝載，則清理程式可獲得足夠的記憶體。

• 確保每天執行。
• 確保在最小儲存庫活動期間執行，方法是相應地在Operations Dashboard中設定維護時段。
• 擴充系統資源（CPU、記憶體、I/O）。

修訂清除依賴估計階段來決定是否有足夠的垃圾要清除。 估算程式會比較目前的大小與上次壓縮後的存放庫大小。 如果大小超過設定的差異，則會執行清理。 大小差異設定為1 GB。 這實際上表示，如果存放庫大小自上次清除執行以來未增加1 GB，則會略過新的修訂清除疊代。

以下為預估階段的相關記錄專案：

• 修訂GC執行： 大小差異為N%或N/N （N/N位元組），因此執行壓縮
• 修訂GC會 非 執行： 大小差異為N%或N/N （N/N位元組），因此現在將略過壓縮

如果系統上存在寫入並行，線上修訂清除可能需要獨佔寫入存取權，才能在壓縮週期結束時確認變更。 系統進入 forceCompact模式，詳情請參閱 Oak檔案. 在強制壓縮期間，會取得獨佔寫入鎖定，以最終認可變更，而不受任何並行寫入干擾。 若要限制對回應時間的影響，可定義逾時值。 此值預設為一分鐘，這表示如果強制壓縮未在一分鐘內完成，壓縮程式將中止，以支援同時提交。

強制壓縮的持續時間取決於以下因素：

• 硬體：尤其是IOPS。 持續時間會隨著IOPS的增加而減少。
• 區段存放區大小：持續時間會隨著區段存放區的大小而增加。

在冷待命設定中，只有主要執行個體必須設定為執行「線上修訂清除」。 在待命執行個體上，不需要特別排定「線上修訂清除」。

待命執行個體上的對應作業是「自動清除」 — 這對應於「線上修訂清除」的清除階段。 在主要執行個體上執行「線上修訂清除」後，在待命執行個體上執行「自動清除」。

預估和壓縮階段不會在待命執行個體上執行。

離線修訂清除可以立即移除舊修訂版本，而線上修訂清除必須說明應用程式棧疊仍在參考的舊修訂版本。 因此，前者可以比後者更積極地移除垃圾，其效果會透過幾個垃圾收集週期進行攤銷。

另請參閱的「離線修訂清除後執行線上修訂清除」一節。 本章.

• 在Windows環境中，一律會強制執行一般檔案存取，因此不會使用記憶體對應存取。 一般建議是，所有可用的RAM都應該配置給棧積，並且應該增加segmentCache大小。 您可以將segmentCache.size選項新增至org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config (例如segmentCache.size=20480)以增加segmentCache。 請記得為作業系統和其他處理序省略一些RAM。
• 在非Windows環境中，增加實體記憶體大小以改善存放庫的記憶體對應。

• 啟用[線上修訂清除]時，應該監視磁碟空間。 當磁碟空間不足時，清理不會執行或會先佔終止。
• 檢查線上修訂清除的完成時間記錄。 此過程不應超過2小時。
• 查核點數目。 如果在壓縮執行時有3個以上的查核點，建議清理查核點。

您可以透過檢查記錄來檢查線上修訂清除是否已成功完成。

例如，「TarMK GC #{}: compaction completed in {} ({} ms), after {} cycles「表示壓縮步驟已成功完成，除非在訊息前面加上」TarMK GC #{}: compaction gave up compacting concurrent commits after {} cycles「」，表示有太多同時負載。

對應地，會出現訊息」TarMK GC #{}: cleanup completed in {} ({} ms」以成功完成清理步驟。

透過JMX公開狀態、進度和統計資料(SegmentRevisionGarbageCollection MBean)。 有關詳細資訊 SegmentRevisionGarbageCollection MBean，讀取 跟隨段落.

可透過追蹤進度 EstimatedRevisionGCCompletion 的屬性 SegmentRevisionGarbageCollection MBean.

您可以使用取得MBean的參照 ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection".

統計資料僅自上次系統啟動後提供。 外部監控工具可用來讓資料超出AEM運作時間。 另請參閱 有關將健康情況檢查附加至Nagios的AEM檔案，作為外部監控工具的範例.

• 線上修訂清除已開始/停止
  • 「線上修訂清除」由三個階段組成：估算、壓縮和清除。 如果存放庫未包含足夠的記憶體，預估可能會強制略過壓縮和清理。 在最新版AEM中，訊息為「TarMK GC #{}: estimation started「標籤預估的開頭， 」TarMK GC #{}: compaction started, strategy={}」標籤壓縮的開頭和「T」arMK GC #{}: cleanup started. Current repository size is {} ({} bytes"會標籤清除的開始。
• 修訂清除取得的磁碟空間
  • 只有在清理階段完成時，才會回收空間。 清理階段的完成會以記錄訊息「T」標示arMK GC #{}: cleanup completed in {} ({} ms「。 後續清理大小為 {} ({} 位元組)和已回收的空間 {} ({} 位元組)。 壓縮地圖寬度/深度為 {}/{} ({} 位元組/{})。」。
• 修訂清除期間發生問題
  • 有許多失敗情況，所有情況都標有「TarMK GC」開頭的WARN或ERROR記錄訊息。

另請參閱 根據錯誤訊息進行疑難排解 一節。

線上修訂清除後不需要進行存放庫完整性檢查。

不過，您可以執行下列動作，在清除後檢查存放庫狀態：

• 存放庫 周遊檢查
• 在清理程式完成後，使用Oak-run工具來檢查是否不一致。 如需如何執行此動作的詳細資訊，請檢視 Apache檔案。 您不需要關閉AEM即可執行工具。

修訂清理健康狀態檢查是 操作控制面板.

狀態為 綠色 如果上次執行線上修訂清除維護工作已順利完成。

它是 黃色 如果「線上修訂清除」維護作業已取消一次。

它是 紅色 如果「線上版次清理」維護作業連續取消三次。 在此情況下，需要手動互動 或「線上修訂清除」可能再次失敗。 如需詳細資訊，請閱讀 疑難排除 一節。

此外，系統重新啟動後，也會重設健康狀態檢查狀態。 因此，新重新啟動的執行個體會在修訂清理健康情況檢查中顯示綠色狀態。 外部監控工具可用來讓資料超出AEM運作時間。 另請參閱 有關將健康情況檢查附加至Nagios的AEM檔案，作為外部監控工具的範例.

透過JMX使用公開狀態、進度和統計資料 SegmentRevisionGarbageCollection MBean。 另請參閱下列內容 Oak檔案.

您可以使用取得MBean的參照 ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection".

統計資料只能從上次系統啟動後使用。 外部監控工具可用於在AEM運作時間以外保留資料。 另請參閱 有關將健康情況檢查附加至Nagios的AEM檔案，作為外部監控工具的範例.

記錄檔也可用來檢查自動清理的狀態、進度和統計資料。

• 執行自動清理時，應該監視磁碟空間。
• 完成時間（透過記錄檔）以確保不會超過2小時。
• 執行自動清理後的區段存放區大小。 待命執行個體上的區段存放區大小應該與主要執行個體上的區段存放區大致相同。

您可以採取數個步驟來尋找及修正問題：

• 首先，檢查記錄專案

• 根據記錄中的資訊，採取適當的動作：

  • 如果紀錄顯示五個錯過的壓縮週期和一個逾時 forceCompact 週期，將維護期間排程為存放庫寫入量低時的安靜時間。 您可以在存放庫測量結果監視工具中檢查存放庫寫入 https://serveraddress:serverport/libs/granite/operations/content/monitoring/page.html
  • 如果清理在維護時段結束時停止，請確定維護任務使用者介面中的維護時段設定夠大
  • 如果可用的棧積記憶體不足，請確定執行個體有足夠的記憶體。
  • 如果反應較晚，區段存放區可能會增長太多，以致於線上修訂清除（即使在較長的維護期間內）無法完成。 例如，如果上週未成功完成線上修訂清除，則建議規劃離線維護，並執行離線修訂清除，將區段存放區恢復到可管理的大小。

A SegmentNotFoundException TarMK在嘗試存取它找不到之儲存單位（區段）時會記錄下來。 有三種情況可能會導致此問題：

1. 一種應用程式，可繞過建議的存取機制（例如Sling和JCR API），使用較低層級的API/SPI來存取存放庫，然後超過區段的保留時間。 也就是說，它會保留一個實體的參照，保留時間超過線上修訂清除（預設為24小時）所允許的保留時間。 此案例為暫時性，不會導致資料損毀。 若要復原，應使用Oak-run工具來確認例外狀況的暫時性（Oak-run檢查不應報告任何錯誤）。 若要這麼做，執行個體必須離線並稍後重新啟動。
2. 外部事件造成磁碟上的資料損毀。 這可能是磁碟故障、磁碟空間不足或意外修改所需資料檔案所致。 在此情況下，執行個體必須離線並使用Oak-run檢查進行修復。 如需如何執行Oak-run檢查的詳細資訊，請閱讀以下內容 Apache檔案.
3. 處理所有其他事件，透過 Adobe客戶服務.

• Oak修訂版本： Oak會以大型樹狀階層來組織所有內容，該階層包含節點和屬性。 此內容樹狀結構的每個快照或修訂版本都是不可變的，而且樹狀結構的變更會以新修訂版本的順序表示。 通常，每個內容修改都會觸發新的修訂。 另請參閱 關注連結.
• 頁面版本： 版本設定功能會在特定時間點建立頁面的「快照」。 通常，新版本會在頁面啟動時建立。 如需詳細資訊，請參閱 使用頁面版本.