修訂清除

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

一旦開始移轉至AEM 6.5永續性格式，存放庫就無法還原回先前的AEM 6.3永續性格式。

在AEM 6.3中，需要更改儲存格式，特別是為了改進線上修訂清理的效能和效果。 這些變更不向後相容，且以舊Oak區段(AEM 6.2和舊版)建立的存放庫必須移轉。

更改儲存格式的其他好處：

• 更佳的可擴充性（最佳化區段大小）。
• 更快的資料儲存垃圾收集。
  
• 未來增強功能的基礎工作。

離線修訂清除將回收除最新一代之外的所有內容，而線上修訂清除則需回收最新兩代。 若是新的存放庫，線上修訂清除在離線修訂清除後首次執行時，不會回收任何空間，因為沒有足夠可回收的代數。

此外，請閱讀本章的「離線修訂清除後執行線上修訂清除」一節。

「線上修訂清除」僅適用於AEM 6.3和更新版本。 此外，如果您使用的是舊版AEM，則需要移轉至新的Oak Segment Tar。

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

線上修訂清除期間會持續監控磁碟空間。 如果可用磁碟空間降至關鍵值以下，該過程將被取消。 關鍵值是儲存庫當前磁碟佔用量的25%，且不可配置。

建議將磁碟的大小至少比最初估計的儲存庫大小大兩三倍。

清除過程中會持續監視空閒堆空間。 如果空閒堆空間降至關鍵值以下，則取消該進程。 關鍵值是透過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位元組），因此運行compaction
• 修訂GC將not運行：大小增量為N%或N/N（N/N位元組），因此現在跳過壓縮

如果系統上存在寫併發，線上修訂清除可能需要獨佔的寫訪問權才能在壓縮週期結束時提交更改。 如oak檔案中詳細說明，系統會進入forceCompact模式。 在強制緊縮期間，獲取獨佔寫鎖，以便最終提交更改而不會任何併發寫入干擾。 若要限制對回應時間的影響，可以定義逾時值。 此值預設為1分鐘，這表示如果強制壓縮未在1分鐘內完成，壓縮過程將中止，以支援併發提交。

力緊的持續時間取決於以下因素：

• 硬體：特別是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.

可使用ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection”獲取MBean的引用。

請注意，統計資料僅自上次系統啟動後可用。 可運用外部監控工具，讓資料超出AEM正常運作時間。 請參閱將健康狀態檢查附加至Nagios的AEM檔案，作為外部監控工具的範例。

• 已開始/停止線上修訂清除
  • 「線上修訂清除」由三個階段組成：估計、壓縮和清理。 如果存放庫未包含足夠的垃圾，估計可能會強制壓縮和清除，以略過。 在最新版AEM中，訊息「TarMK GC #{}: estimation started」會標籤估計的開始，「TarMK GC #{}: compaction started, strategy={}」會標籤壓縮的開始，而「TarMK GC #{}: cleanup started. Current repository size is {} ({} bytes」會標籤清除的開始。
• 修訂清除獲取的磁碟空間
  • 只有在清理階段完成時，才會回收空間。 清理階段的完成由日誌消息「TarMK GC #{}: cleanup completed in {} ({} ms」標籤。 清理後大小為{}（{}位元組），空間回收了{}（{}位元組）。 壓縮映射權重/深度為{}/{}({} bytes/{})。」
• 修訂清除期間發生問題
  • 故障情況很多，所有情況都標籤有「TarMK GC」開頭的「WARN」或「ERROR」日誌消息。

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

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

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

• 儲存庫遍歷檢查
• 清理程式完成後，請使用oak-run工具來檢查不一致之處。 有關如何執行此操作的詳細資訊，請查看Apache文檔。 您不需要關閉AEM即可執行工具。

修訂清除運行狀況檢查是操作儀表板的一部分。

如果「線上修訂清除」維護任務的上次執行成功完成，則狀態將為GREEN。

如果「線上修訂清理」維護任務取消一次，則該任務將為YELLOW。

如果「線上修訂清理」維護任務連續取消三次，則該任務將為RED。 在此情況下，需要手動 互動，否則線上修訂清除可能會再次失敗。有關詳細資訊，請閱讀下面的疑難解答部分。

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

如何監視待機實例的自動清除？

狀態、進度和統計資訊通過JMX使用SegmentRevisionGarbageCollection MBean公開。 另請參閱下列Oak檔案。

可使用ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection”獲取MBean的引用。

請注意，統計資料僅自上次系統啟動後才可用。 可運用外部監控工具，讓資料超出AEM正常運作時間。 另請參閱將健康狀態檢查附加至Nagios的AEM檔案，作為外部監控工具的範例。

日誌檔案還可用於檢查「自動清理」的狀態、進度和統計資訊。

在備用實例的自動清理期間需要監控哪些內容？

• 運行「自動清理」時應監視磁碟空間。
• 完成時間（透過記錄檔），以確保不會超過2小時。
• 執行「自動清除」後，Segmentstore大小。 備用執行個體上的segmentstore大小應與主執行個體上的大小大致相同。

• 首先，檢查日誌條目
  
• 視記錄檔中的資訊而定，採取適當動作：
  • 如果日誌在forceCompact週期中顯示五個缺少的緊湊週期和超時，則當儲存庫寫入量較低時，將維護窗口安排為安靜時間。 您可以在位於https://serveraddress:serverport/libs/granite/operations/content/monitoring/page.html的存放庫量度監控工具中檢查存放庫寫入
  • 如果清理在維護窗口的末尾停止，請確保維護任務用戶介面中維護窗口的配置足夠大
  • 如果可用的堆記憶體不足，請確保實例具有足夠的記憶體。
  • 如果出現延遲反應，區段存放區可能會成長得太多，以致「線上修訂清除」無法在較長的維護期間內完成。 例如，如果上週未完成成功的線上修訂清除，則建議您規劃離線維護並執行離線修訂清除，以便將區段存放區恢復為可管理的大小。

當TarMK嘗試存取找不到的儲存單元（區段）時，會記錄SegmentNotFoundException。 有三種情況可能會導致此問題：

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

需要清理的儲存庫大小和修訂的數量決定了清理的持續時間。

• Oak修訂： Oak以由節點和屬性組成的大型樹狀結構階層組織所有內容。此內容樹的每個快照或修訂都不可修改，對樹的更改將以新修訂的序清單示。 通常，每個內容修改都會觸發新修訂。 另請參閱追隨連結。
• 頁面版本： 版本設定會在特定時間點建立頁面的「快照」。通常，頁面啟動時會建立新版本。 如需詳細資訊，請參閱使用頁面版本。