修訂清除

TarMK的永續性格式將隨AEM 6.5而變更。這些更改不需要主動遷移步驟。 現有儲存庫將進行滾動遷移，該遷移對用戶是透明的。 第一次AEM 6.5（或相關工具）存取儲存庫時，就會開始移轉程式。

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

在AEM 6.3中，需要變更儲存格式，尤其是為了改善「線上修訂清除」的效能和效能。 這些變更不向後相容，而且必須移轉使用舊Oak Segment（AEM 6.2和舊版）建立的儲存機制。

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

• 更佳的延展性（最佳化的區段大小）。
• 更快的Data Store廢棄項目收集。
  
• 未來增強功能的基礎工作。

「離線修訂清除」可回收除最新一代產品之外的所有內容，而「線上修訂清除」則可回收最新兩代產品。 對於新儲存庫，聯機修訂清除在離線修訂清除後首次執行時不會回收任何空間，因為沒有可回收的舊代。

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

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

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

在聯機修訂清除期間，會持續監視磁碟空間。 如果可用磁碟空間降至臨界值以下，則將取消該過程。 關鍵值是儲存庫當前磁碟佔用空間的25% ，且不可配置。

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

清除過程中會持續監視空閒堆空間。 如果空閒堆空間降到臨界值以下，則取消該進程。 臨界值是透過org.apache.jackrabbit.oak.segment.SegmentNodeStoreService#MEMORY_THRESHOLD來設定。 預設值為15%。

Recommendations for minimum compaction heap sizing are not separed for the AEM memory sizing recommendations. 一般規則是：如果AEM例項的大小足夠足以處理使用案例和預期的負載，則清除程式將獲得足夠的記憶體。

• 確保每天執行。
  
• 通過相應地在Operations Dashboard中配置維護窗口，確保在最小儲存庫活動期間執行該操作。
• 擴展系統資源（CPU、記憶體、I/O）。

「修訂清除」依賴於估計階段來判斷是否有足夠的廢棄項目需要清除。 估計器將當前大小與上次壓縮後儲存庫的大小進行比較。 如果大小超過配置的增量，則將運行清理。 大小增量設定為1 GB。 這實際上意味著，如果自上次清理運行以來儲存庫大小未增長1 GB，則將跳過新修訂清理小版本。

以下是估計階段的相關日誌條目：

• 版本GC將運行：大小delta為N%或N/N（N/N位元組），因此運行compaction
• 修訂版GC將not運行：大小delta為N%或N/N（N/N位元組），因此現在正在跳過壓縮

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

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

• 硬體：特別是IOPS。 持續時間會隨著IOPS的增加而減少。
• 區段商店大小：持續時間會隨著區段儲存區的大小而增加。

待機實例上如何執行聯機修訂清除？

在冷備用設定中，只需將主實例配置為運行聯機修訂清除。 在備用實例上，無需特別計畫「線上修訂清除」。

備用實例上的相應操作是「自動清理」，這對應於「聯機修訂清理」的清理階段。 在主實例上執行聯機修訂清除後，在備用實例上運行自動清除。

估計和壓縮階段將不會在備用實例上運行。

「離線修訂清除」可立即移除舊修訂，而「線上修訂清除」則需要考慮應用程式堆疊仍在參照的舊修訂。 因此，前者可以比後者更積極地去除垃圾，在少數垃圾收集週期中，效果被攤銷。

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

• 在Windows環境中，一律強制執行一般檔案存取，因此不會使用記憶體映射存取。一般建議是，所有可用的RAM都應分配給堆，並且segmentCache大小應增加。 您可將segmentCache.size選項新增至org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config（例如segmentCache.size=20480），以增加segmentCache。 請記得為作業系統和其他進程保留一些RAM。
• 在非Windows環境，增加物理記憶體的大小，以改進儲存庫的記憶體映射。

• 啟用「聯機修訂清除」時，應監視磁碟空間。 清除將不運行，或者當磁碟空間不足時，將以搶佔方式終止。
• 檢查日誌中有關「Online Revision Cleanup（聯機修訂清除）」的完成時間。 不得超過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正常運作時間的限制。 請參閱AEM檔案，以附加健康狀況檢查至Nagios，做為外部監控工具的範例。

• 聯機修訂清除已啟動／已停止
  • 線上修訂清除由三個階段組成：估計、壓縮和清理。 如果儲存庫中沒有足夠的廢棄項目，估計可能會強制壓縮和清除。 在最新版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」標籤。 後清理大小為{}（{}位元組），空間回收{}（{}位元組）。 壓縮圖權重／深度為{}/{}（{}位元組/{}）。"
• 修訂版清除期間發生問題
  • 故障情況很多，所有都標有WARN或ERROR日誌消息，以「TarMK GC」開頭。

另請參閱下面的基於錯誤消息進行故障排除一節。

聯機修訂清除後，不需要儲存庫完整性檢查。

但是，您可以執行下列操作來檢查清理後的儲存庫狀態：

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

The Revision Clean-up Health Check is apt of the Operations Dashboard.

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

如果「聯機修訂清除」維護任務被取消一次，則它將為YELLOW。

如果「聯機修訂清除」維護任務已連續取消三次，則該任務將為RED。 在這種情況下，需要手動 交互，否則「線上修訂清理」可能再次失敗。如需詳細資訊，請閱讀下方的疑難排解一節。

另請注意，系統重新啟動後，Health Check狀態將會重設。 因此，新重新啟動的實例在Revision Cleanup Health Check上將顯示綠色狀態。 您可運用外部監控工具，讓資料不受AEM正常運作時間的限制。 請參閱AEM檔案，以附加健康狀況檢查至Nagios，做為外部監控工具的範例。

如何監視備用實例上的自動清理？

使用SegmentRevisionGarbageCollection MBean，可透過JMX公開狀態、進度和統計資料。 另請參閱以下Oak documentation。

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

請注意，統計資料僅在上次系統啟動後才可用。 您可運用外部監控工具，讓資料不受AEM正常運作時間的限制。 此外，請參閱AEM檔案，以附加健康檢查至Nagios，做為外部監控工具的範例。

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

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

• 運行「Automatic Cleanup（自動清理）」時，應監視磁碟空間。
• 完成時間（透過記錄檔），以確保不超過2小時。
• 區段儲存在「自動清除」執行後的大小。 備用實例上的段儲存的大小應與主實例上的段儲存的大小大致相同。

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

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

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

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

• Oak revision: Oak將所有內容組織在由節點和屬性組成的大型樹狀結構中。此內容樹的每個快照或修訂都是不可變的，對樹的更改將表示為新修訂的序列。 通常，每次內容修改都會觸發新修訂。 另請參閱 Follow link。
• 頁面版本： 版本控制會在特定時間點建立頁面的「快照」。通常，在啟動頁面時會建立新版本。 如需詳細資訊，請參閱使用頁面版本。